Meetup “Automated testing & continuous deployment for mobile apps” tomorrow

Mark Prichard from CloudBees, myself, and Matt Solnit from SOASTA will deliver a joint talk Thursday evening at Silicon Valley Cloud Computing Group.

Our part of the talk will take an iOS application and a backend Java server, then discuss how you can set up the pipeline of continuous build and test for them on Jenkins. The demo will be based on the CloudBees platform and we think it’s easier to do it that way than setting everything up on your own, but the setup should equally apply to your local Jenkins installation.

The part of the talk from Matt highlights SOASTA’s CloudTest product, which is basically a robot tha emulates user interaction on the device. My understanding of this is that it’s similar to Frank and KIF, but it comes with a recorder that lets you do “programming by example” — you manually interact with the test target app, and the recorder will turn that into a test scenario (Selenium IDE, anyone?)

Apple has locked down the iOS application development and distribution which makes the automated testing setup more painful than it should be, but because of that, I think a talk like this that shows the whole setup is worthwhile.

The event will be Thursday evening, at Yahoo! Campus in Sunnyvale. Please join us if you can. The event is free but requires RSVP. Beer and pizza are provided.

Push changes directly into BuildHive, and never run tests again!

On top of pull requests auto-build, BuildHive now allows you to push changes directly in via ssh. I call this feature “validated merge”.

If you are an active developer of a repository, chances are that you don’t use pull requests to send in changes. You probably just push changes directly into your repository instead. But one of the common problems of doing this is that if your change breaks the build, you are going to discover it too late. With validated merge, this problem will never happen again, and this is how it works.

First, you add the buildhive user as a collaborator to your repository, so that it can push when the build is done. I didn’t feel comfortable doing this automatically, so you need to do it explicitly.

Second, login to BuildHive (just once is suffice, so that it learns your public keys you registered with GitHub), head to the job page in BuildHive (like this), and click “Git repository for validated merge” link from the left. Click the copy button to copy the “git remote add” command, paste that in your shell, and execute that on your local repository. This will add BuildHive as a remote repository.

Preparation is now complete. Go modify code like you normally do by creating commits, and when you are ready to push, push your changes to “jenkins” instead of pushing to “origin”. If you are on a branch, replace “master” with the branch name you are working on:

$ git push jenkins master

BuildHive will check out the current tip of the specified branch in GitHub, merge that with the changes you just submitted, then do the build and run tests. If the merge result successfully completes the build and tests, the result will be pushed to GitHub by BuildHive.

If you are unlucky and your changes weren’t as good as you thought, you’ll learn that it didn’t pass the builds. You then stash your work, come back to the broken changes, and rework those. You probably don’t remember which commit you pushed to BuildHive, so BuildHive provides a tag you can fetch into your workspace to get to it.

$ git stash
$ git fetch -n ssh:// tag changes/45
$ git checkout changes/45
$ … make edits ...

You can add more commits to correct the problem, or you can even amend your commits — since your changes didn’t land in the repository, amending, rebasing, and so on is just fine. You can then re-push your changes and then go back to what you were working on before interrupted by a failure.

$ git push jenkins HEAD:master
$ git checkout master
$ git stash pop
… resume the work you were doing ...

If you’ve already headed home, your colleague can do this workflow for you.

Your time is precious. Don’t waste it by watching your laptop to complete tests. Instead, let BuildHive do it for you!

By the way, this is a feature already available in Jenkins Enterprise by CloudBees, so if you like the workflow but your source code isn’t in a public GitHub repository, you can do the same thing with any Git repository inside your firewall.

Upcoming San Francisco training

CloudBees will be hosting another training in San Francisco Bay Area in January 26, 2012, and Feburary 23rd in Tokyo.

This 1-day training starts with the basics and then covers some of the advanced techniques, especially in combination with some plugins. As we deliver this training more, we gradually adjusted the material to cover more advanced topics, like promotion, build pipeline, parameterized triggers, and so on — the kind that’s getting more traction lately as Jenkins starts to encompass continuous delivery.

And for me, this training will be the first to use the latest “install plugins without restart” feature, so that should help with attendees keeping the focus a bit.

In these trainings, we cap the number of attendees to a fairly small size so that I can pay attention to each attendees enough. People normally bring in questions that go beyond the training curriculam to discuss the problems they face in their day-to-day Jenkins administrations. I welcome those, too!

If you are interested, please sign up while the seats are available!

GitHub releases Janky

I saw an announcement that GitHub released Janky today.

I initially got confused a bit because the post says Janky is a continuous integration server, which got me thinking that it’s something you’d use instead of Jenkins, but as I read more about it, it became clear that it’s something you use in conjunction with Jenkins — it’s an application that sits between GitHub API, Jenkins API, and Hubot chat bot to help you create jobs on Jenkins, set up build triggers from push notifications, and so on. So for those who are using GitHub for hosting repositories and Campfire for chat, this is a nice interface that lets you get more out of your Jenkins.

The other thing I like here is that Janky pretty much requires you to run all the services “on the cloud”, because they need to talk to each other via HTTP calls. This makes it a great fit with CloudBees’s DEV@cloud, the hosted Jenkins service CloudBees provide. So between GitHub as a hosted service for repositories, Campfire for a hosted service for chats, and DEV@cloud for a hosted service for Jenkins, you can start to see the power of integration between hosted services. Greater collaboration of web services is a future I can believe in!

And if you like the idea of GitHub + Jenkins but you don’t do Campfire, you might find the Jenkins GitHub plugin useful. This plugin lets you set up a push-based build triggering from your GitHub project with a single checkbox.

Finally, as an icing on the cake, they got this nice thing to say about Jenkins:

The power, vast amount of plugins and large community of the popular CI server all wrapped up in a great experience.

One more validation to the great momentum of the Jenkins project. Yay!

Congrats to the GitHub guys for the launch of Janky!

Webinar: Jenkins Enterprise by CloudBees

On Janurary 10th, I’ll be doing a webinar about Jenkins Enterprise by CloudBees (formerly known as Nectar, which we renamed with the permission of the community.)

Jenkins Enterprise is Jenkins LTS + a number of CloudBees’ value-add plugins that help large and serious users, with the support. This release contains a number of new plugins, most notably the template plugin, which allows people to manage a large number of similar jobs, creating more domain friendly configuration mechanism, as well as means for the administrators to force certain practice on jobs.

The release also includes improvements to existing plugins — folders can now have views defined within them, and with VMWare, you can now tell Jenkins to use all computers in a specific folder, as opposed to configure individual machines one by one. There’s also a new job scheduling mode that makes Jenkins prefer idle slaves over partially used slaves that already have your workspace. And so on.

This release also lets you run these value-add plugins on top of non-LTS stock Jenkins.

All things combined, I think we got something interesting for many Jenkins users. Hope you can join us in this webinar.

Introducing template plugin

The Nectar 11.10 release that we just made has the template plugin, which I think is one of the very useful plugins that we added to Nectar that’s not available in open-source Jenkins. So I wanted to talk about it a bit.

Many serious Jenkins users have had this common problem that they’ve got a lot of jobs that look similar. JENKINS-3157, which is currently the most voted issue in JIRA, speaks to that same pain point. The template plugin is my answer to this problem.

What this plugin does, is to allow you to define a “model”. A model is an abstract concept that fits your particular problem domain. You do this through defining a set of attributes, kind of like how you define a class with a set of properties in Java, or how you define a table with a set of columns in database. You then define a transformation, which converts this model into something that Jenkins understands.

Creating a template

This is all rather abstract, so let’s look at a concrete example. We are going to define a hello world builder template, which lets you enforce the standard way to greet someone. You can then use this template to greet a lot of people in many jobs.

Installing this plugin, you get the “templates” menu on the left. You can click that and create a template:

You create a builder template from the same faimilar wizard you use to create a job:

Then here is the main meat.

There are two main things to configure here: attributes and a transformer.

When you define a template, you first ask yourself “what do I want my users to enter when they use my template?” The answer to that question becomes attributes. In this hello world builder, we want the user to configure who we are saying hello to, so we define one attribute named “target” for this purpose. The user should see the single text field for this, so we choose the type accordingly. The display name and inline help are self-explanatory. They control what the user will see when they are editing their free-style projects to use our new builder.

The second question you should ask when you define a template is “how does it execute?” (or more generally “how does it map to the terms Jenkins understands?”) The answer to that question becomes the transformer. In this tutorial, our builder will turn into a shell script that says hello (whereas your real template would probably turns into a shell script that gets some real work done, like building a component, running a test, etc.) So we’ll choose “generate a shell script to execute via Groovy”.

In the text area, we’ll fill the shell script that this build step is going to execute, but with expressions here and there of the form ${...} (because this is a Groovy template). ${target} refers to the actual value of the target attribute we defined above, and ${build.fullDisplayName} is a Groovy expression to access the getFullDisplayName() method (which returns the full name of the build) of the build object, which refers to the current build in progress. The ${build.fullDisplayName} needs to be quoted because this is going to look like test #1, and # gets interpreted by shell as a comment sign unless you quote it.

Using a template

Now that we have our first builder template, let’s create a free-style project that actually uses it. Go back to the Jenkins top page, and create a new free-style project. You’ll be taken to the configuration page. This part of Jenkins should be already familiar to you.

When you click “add build step”, you should see the newly created “Say Hello World” builder. You click it, and you see the say hello world builder added to your project. And you see the “target” attribute you defined in the configuration page.

I configured this to say hello to Kohsuke. If we save it and run it, lo and behold, you’ll see that it works.

[workspace] $ /bin/sh -xe /tmp/
+ echo Hello to Kohsuke from test #1
Hello to Kohsuke from test #1
Finished: SUCCESS

This allows you as the build guy to create and enfroce a certain way your stuff gets built/tested, and your users get shielded from all the gory details of how the build/test actually get done. You can create a layer between Jenkins and your users, and make Jenkins talk in the language your users understand, instead of making them talk in the language Jenkins understands. This is one of the points of the template plugin.

Changing a template

Now, let’s change the definition of the template, and see how it affects the instances.

We’ll go back to the template definition by going back to the top page, clicking the “Templates” link in the left, and clicking the configuration icon on the right to the “Say Hello World” template.

Instead of saying hello, now we make it say good evening.Click “save” to save this new definition:

Now, when you update the template definition, all the use of this template automatically reflects the change you made. So without revisiting the configuration page of the freestyle job, let’s simply schedule another build and see its console output:

[workspace] $ /bin/sh -xe /tmp/
+ echo Good evening to Kohsuke from test #2
Good evening to Kohsuke from test #2
Finished: SUCCESS

This is another point of the template plugin — when you change the definition, all the uses of this template get updated right away. So if you need to tweak how those high-level abstract concepts map to the lower level command sequences, you only need to edit it once and save it.

Try it out for yourself

If you like what you’ve read so far (I hope you do), please play with this. You can either download the whole Nectar and play it in a separate sandbox, or you can enable the secondary update center to install these plugins on your OSS Jenkins deployments.

And there’s a lot more to the template plugin, which I hope to write about in a few days.

Jenkins training in New York next week

As a follow up to the successful sessions we held in London, San Francisco, and Tokyo, CloudBees will be holding two additional Jenkins training sessions in the coming few months, in San Francisco and New York City. The San Francisco session has already sold out, but there are several remaining slots for the New York session (interested individuals can register here).

I’m pleased to announce that I will be personally running the New York session. Our intent is to keep the number of participants low so as to allow for maximum interaction — aside from the caricculum, I often end up discussing challenges and problems individual attendees are facing with them, and it works only if we have a smaller room, and people seem to like that. As I’ve noted before, interacting with Jenkins users is always an enlightening experience and it’s also extremely helpful for me personally as I continuously work on software improvements for the project.

Like our London session, this will be aimed at users that already have a working knowledge of Jenkins. Once you get the build and tests automated, what can you do from there? The idea with these sessions is to help improve on advanced Jenkins functionalities to answer this question, including creating bigger automated workflows / broader choreographies, code quality metrics, automated deployment, and so on.

I look forward to seeing you there!

Upcoming Training in London

On June 1st, CloudBees will be hosting a 1-day Jenkins training in London, and I’ll be delivering it. Based on the experience of past deliveries of the training, this time I’m making some significant updates to the material to cater toward more experienced users and admins, about topics that range from automated code quality tracking to distributed builds, security setup to how you do continous delivery, build promotions to parameterized builds.

The training is capped by a small number of people, so it’s also interactive. I’ve enjoyed answering interesting and specific questions people bring in and point them to different plugins. In addition, for me, seeing people use the software also helps me understand how to improve them.

This is the first time we do this in Europe, and I’m hoping you’ll come join us. And if you are not in London, looks like my boss has signed me up for future trainings in San Francisco and New York, and if you have suggestions about other cities, please let us know!

Upcoming Webinar “Mastering Jenkins Security”

I’ll be doing another Jenkins webinar titled “Mastering Jenkins Security” in the next Thursday 10am Pacific Time. It’s a free event, so please register.

After the first webinar, I got a number of feedbacks about the future webinar topics. So when we thought about doing the next one, this came fairly naturally. Unlike the first one, this time the idea is to pick one topic and go do some in-depth discussions. It’s harder to do in a conference, and so I think it’s better suited for webinars.

By default, no security is enabled in Jenkins, so in an environment where a stricter access control is more benefitial, an administrator needs to set this up to suit their needs, and there’s just a lot of different ways people want to configure it. So in this webinar, I’ll start by outlining the basic design of the security system in Jenkins — authentication and authorization — so that you can build a sufficient mental model of how it works, how they interact, and how it can be made to fit your needs.

We’ll then go through the major implementations of those two pluggability points, so that you can pick the right implementation for your needs. There are some plugins, like Active Directory plugin or OpenID plugin, that tightly integrates with respective systems that provide great integration experience. Then there are other plugins, like script security realm, which provides a general purpose mechanism that can be used to integrate Jenkins with arbitrary systems with little effort. Then there’s an entirely different approach of delegating authentication outside Jenkins to the front end reverse proxy. On the authorization side, there are lesser but still a number of options that you can choose from.

Aside from the authentication/authorization, I’ll discuss the security implications of running builds in Jenkins and other standard webapp security considerations, such as cross-site scripting problems, cross-site request forgery issues, and other attack vectors. I think it’d be useful for those who run Jenkins for a larger team.

So once again, please register if you are interested in attending, and if you have future topic suggestions, please let me know!