Archive for March, 2015
Long time users of our Pulse Continuous Integration Server would know that we don’t believe in posting long-term roadmaps. They just never reflect a changing reality! But we have always been happy to discuss features with customers, including keeping our issue tracker (creaky old version of Jira that it is) completely open for all to see and contribute. In that spirit I’d like to talk a little about where we’re heading with Pulse in the near term, the bit that can be predicted, in a format more digestible than disparate issues.
The next version of Pulse (as yet unnamed), will have updates focused on a few areas:
- Upgrades of underlying libraries including Equinox, Spring, Spring Security, Hibernate, Jetty, Quartz, EhCache and more. If you haven’t seen a lot of visible changes reported recently this is why: these upgrades have occupied the first part of this development cycle. These are truly the most boring of all changes, which we hope you won’t notice directly at all! What you will notice, though, is a payoff of this strong foundation over time.
Major updates to the administration interface. The interface works well enough at the moment but could be improved in a couple of key areas: discoverability and efficiency. Key goals for these updates include:
- Improving the visibility of the most commonly-used configuration via overview pages.
- Making it easier to discover what is overridden (via templating) and where.
- More efficient navigation, especially through the template hierarchy.
- Modernisation to take advantage of HTML 5 (which the current interface predates).
These changes are big enough to warrant a dedicated blog post at a future point.
- Improved visibility of the build environment. When builds fail in curious ways the culprit is often a small difference in the environment. Pulse currently publishes environment information via implicit env.txt artifacts, but these haven’t kept up to date with the variety of options Pulse now gives for specifying build properties.
- Improvements to the Windows experience. In 2.7 work was done to improve Windows service support, but more could be done to streamline the setup process in particular.
As always we will also be working on dozens of smaller improvements and suggestions from our user base, most of which fall under one of:
- UI polish, especially in the reporting interface.
- Increased flexibility of project and build configuration.
- Updated support for modern versions of build tooling.
The Android development tools project has seen big changes over the last year. The original Eclipse ADT development environment was superseded late last year by Android Studio — a new IDE based on Intellij. Under the hood Android Studio also uses a new command line build system based on Gradle, replacing the previous Ant-based system. I’ve been keen to find out how these changes impact the integration of Android test reports with continuous integration servers like Pulse.
- Android JUnit Report is redundant.
- Run on-device Android tests with:
- Collect reports from:
The original Ant-based build system for Android didn’t produce XML test reports for instrumentation tests (i.e. those that run on-device), prompting me to create the Android JUnit Report project. Android JUnit Report produced XML output similar to the Ant JUnit task, making it compatible with most continuous integration servers. The good news is: Android JUnit Report is now redundant. The new Gradle-based build system produces sane XML test reports out of the box. In fact, they’re even more complete than those produced by Android JUnit Report, so should work with even more continuous integration servers.
The only downside is the documentation, which is a little confusing (while there are still documents for the old system about) and not very detailed. With a bit of experimentation and poking around I found how to run on-device (or emulator) tests and where the XML reports were stored. With a default project layout as created by Android Studio:
ASDemo.iml app/ app.iml build.gradle libs/ proguard-rules.pro src/ androidTest/ main/ build.gradle gradle gradle.properties gradlew gradlew.bat local.properties settings.gradle
You get a built-in version of Gradle to use for building your project, launched via gradlew. To see available tasks, run:
$ ./gradlew tasks
(This will download a bunch of dependencies when first run.) Amongst plenty of output, take a look at the Verification Tasks section:
Verification tasks ------------------ check - Runs all checks. connectedAndroidTest - Installs and runs the tests for Debug build on connected devices. connectedCheck - Runs all device checks on currently connected devices. deviceCheck - Runs all device checks using Device Providers and Test Servers. lint - Runs lint on all variants. lintDebug - Runs lint on the Debug build. lintRelease - Runs lint on the Release build. test - Run all unit tests. testDebug - Run unit tests for the Debug build. testRelease - Run unit tests for the Release build.
The main testing target test does not run on-device tests, only unit tests that run locally. For on-device tests you use the connectedAndroidTest task. Try it:
$ ./gradlew connectedAndroidTest ... :app:compileDebugAndroidTestJava :app:preDexDebugAndroidTest :app:dexDebugAndroidTest :app:processDebugAndroidTestJavaRes UP-TO-DATE :app:packageDebugAndroidTest :app:assembleDebugAndroidTest :app:connectedAndroidTest :app:connectedCheck BUILD SUCCESSFUL Total time: 33.372 secs
It’s not obvious, but this produces compatible XML reports under:
with names based on the application module and device. In your continuous integration setup you can just collect all *.xml files in this directory for reporting.
Although the new build system has killed the need for my little Android JUnit Report project, this is a welcome development. Now all Android developers get better test reporting without an external dependency. Perhaps it will even encourage a few more people to use continuous integration servers like Pulse to keep close tabs on their tests!
To all Pulse customers, existing and potential, a bit of news: we’ve applied some long-overdue changes to pricing. Well, not changes so much as clarification! Since the initial release of Pulse we’ve always favoured an up-front pricing policy. We loathe hidden pricing designed to lure you into a lengthy, pushy sales process. So our sales front page has always included pricing information.
However, the pricing on the page didn’t show the full reality. We had three tiers of pricing for 1, 5 and 15 agents, then the option of license 10 packs on top. In practice customers often asked a few questions:
- Can we get a more specific number of agents, e.g. 10?
- Can Pulse handle large numbers of agents, well beyond 15?
- Do discounts apply as the number of agents continues to grow?
In all cases the answer has been yes. We aim for flexibility, and have allowed anyone that asked to purchase a smaller number of agents at a time. Pulse can certainly handle many more than 15 agents: some customers have hundreds in production and we’ve always offered discounts for high numbers.
Thus it is about time we reflected reality in our published prices. From now on there are no defined agent pack sizes: you start with a single agent license for US$900, then add as many additional agents as you need. Agents are priced on a sliding scale so they become progressively cheaper as your installation grows. You can see this clearly on our updated sales page.
What does this mean for existing customers? As a matter of policy: no existing customer will lose out. If you have a deal better than the new published pricing, that deal remains. This may mean you can get more agents free, or a discounted renewal price next time around. For reference: the original single agent license is now US$50 cheaper, and this will translate to a US$25 discount for our existing Pulse Standard License holders. The pricing for 5, 15 and 25 agents remains identical, so many customers will see no change. Larger licenses will be dealt with individually as they come up for renewal.
We think this new pricing better reflects our aim to be both up front and flexible. If you have any questions, please contact sales.
You are currently browsing the a little madness blog archives for March, 2015.