Thursday, July 28, 2011

Kohsuke wins an "O’Reilly Open Source Award"

I am very proud to announce that Kohsuke Kawaguchi just received an O'Reilly Open Source Award!

These awards recognize "individual contributors who have demonstrated exceptional leadership, creativity, and collaboration in the development of open source software" - and this certainly describes Kohsuke's talent very well.

I am even prouder that Kohsuke received this price despite the recent Jenkins/Hudson debacle: this demonstrates that community recognition doesn't just magically happen by forking code, this is something that you build over time, by engaging with your community, respecting it and building trust over time. This is exactly what Kohsuke has done over the last seven years with the Jenkins community.

Kohsuke, you are an authentic person and an outstanding open source leader, I am very proud to have you part of the CloudBees team.



Sacha Labourey, CEO
Follow CloudBees:
Facebook Twitter

O'Reilly Open Source Awards Recognize Kohsuke and Jenkins

Good news here in the hive! Our very own Kohsuke Kawaguchi was announced as a winner of the 7th Annual O'Reilly Open Source Awards, which were awarded earlier today at OSCON 2011 in Portland, Oregon.

The award recognizes individual contributors who have demonstrated leadership, creativity, and collaboration in the development of open source software. Although Kohsuke feels honored that his work on Jenkins (formerly Hudson) has been publicly recognized, he's quick to deflect credit to the thriving community that has backed the project for so many years.

We certainly think he deserves some credit, though; he wrote the majority of the original Hudson/Jenkins code on his own. Plus, the expertise he's acquired in 10+ years of software development has been a key enabler for various advanced features of Jenkins. Not only has Kohsuke shown exemplary technical leadership, he has also attracted scores of talented developers to contribute to Jenkins in the form of 400+ plugins. And he has helped attract more than 23,000 sites to use Jenkins.

Finally, Kohsuke has brought Jenkins to the cloud, as part of our DEV@cloud service. Development teams have instant access to Jenkins build, test and packaging services, as well as unlimited, pay-as-you-go scalability in the cloud, without the worry of configuring and maintaining build servers.

Don't miss out on Kohsuke’s upcoming "Mastering Continuous Integration with Jenkins/Hudson" training in the Bay Area on August 16th, in London on September 23rd and in Tokyo later this fall (date to be announced). You can sign up here.

We hope you'll join us in congratulating Kohsuke for all of his hard work!
-- Lisa

Follow CloudBees:
Facebook Twitter

Wednesday, July 27, 2011

Enterprise Jenkins with SVN: A Bit o' Honey from WANdisco and CloudBees

Yet another partner has joined us here in the Bee Hive: WANdisco, well-known experts in Apache Subversion-based software and services. WANdisco now offers Jenkins -- with higher-level Jenkins support provided by CloudBees -- as an integrated part of their uberSVN platform. uberSVN expands Apache Subversion into a free and open application lifecycle management (ALM) platform, complete with integrated "social coding" environment.

As you probably know, Jenkins is an easy-to-use, continuous integration system to manage and control the application development lifecycle, including build, documentation, testing, and packaging. It can watch for code changes in uberSVN repositories, and automatically do builds, initiate tests, notify users, roll changes backward or forward, schedule, monitor, and manage external time-based cron jobs, and perform operations on remote machines. So you can focus on writing software, not managing and monitoring the build process.

As of today, you can download Jenkins, together with enterprise support, from WANdisco’s new uberApps Store. If you already use uberSVN, get integrated Jenkins free by clicking the "update" button in your platform console.

If you want to extract even more juice from Jenkins, stay tuned… Nectar, CloudBees' professional version of Jenkins, will also be available on the uberApps store soon. Nectar offers enterprise support, a stable release cycle, and additional plug-ins to make Jenkins even more powerful.

See it yourself in a webinar (well, two)…

  1) Want to see how easy it is to deploy Jenkins with SVN and learn best practices for Jenkins? Join us for a free webinar at 9 AM Pacific, on Sept 14th, Automating ALM with Jenkins in the uberSVN Platform.

  2) Join us today for insights from Jenkins expert Stephen Connolly (the weather icon guy): Authentication and Authorization in Jenkins. Sign up here for the webinar TODAY (July 27th) at 12:00 PM ET, but no worries if you can't make it. Leave a comment or just check back here on the blog -- we’ll be posting the recording soon.


Follow CloudBees:
Facebook Twitter

Tuesday, July 26, 2011

Instant CouchDB - Watch the CloudBees Ecosystem in Action

You've probably heard us talk about our new CloudBees Ecosystem, which expands our instant Java-in-the-cloud goodness to include partner companies. With the Ecosystem, you get a la carte services from Cloudant, New Relic, Sauce Labs, JFrog and Sonar on the CloudBees platform, where you can build, deploy, test, manage and monitor applications running in the cloud.

It's a big step forward in realizing benefits of the cloud – get whatever services you want, when you want them, pay only for what you use. You can easily turn them off and on, and you manage them from a single location, CloudBees GrandCentral.

Best of all, it's supremely easy to get started and be productive fast! Watch one of our favorite PaaS architects, Michael Neale, activate Cloudant's CouchDB NoSQL database on the Ecosystem in just a few seconds, then create and deploy a live URL shortening service,

Bonus at the end: Michael demos how to create Views in CouchDB.

If you like the video, you might also enjoy this tutorial on building an app with Cloudant and CloudBees.

After you watch the video, leave us a comment and tell us – can it get any easier? If so, how?!

Spend your time writing software, not managing services from various vendors or maintaining machines. Try the CloudBees Ecosystem...


Follow CloudBees:
Facebook Twitter

Monday, July 25, 2011

CloudBees Raises Series-B from LightSpeed Venture Partners

Sometimes, you can’t be sure why, everything seems to go wrong. Wrong timing, wrong sequence, wrong ideas, wrong team. Just all wrong.

And sometimes, things seem to unfold perfectly: the team is great, the chemistry happens, the ideas are good, the timing is right. Not that hard work is not required or that you don’t make mistakes, but even those seem to have a purpose.

For now, CloudBees seems to fit in that second category. We launched the company 16 months ago, have raised 4m USD last year from Matrix Partners and the incomparable David Skok, joined forces with two great companies (InfraDNA and Stax Networks) and released the only Java PaaS that covers the complete application lifecycle, from development to production, in GA, with full support for SaaS partners as part of the platform. In the meantime, the team has grown from 5 to 27 and we will be opening our first office in Boston this week, which will primarily be serving as the mothership for our sales and marketing team – our engineering team being mostly located somewhere else on Earth.

While it is typically pretty hard to have any kind of certainty in this type of context, I have two: i) the PaaS market is going to be incredibly big and strategic and ii) it is unclear at what point it will fully trigger. And the timing won’t just depend on CloudBees delivering on a great platform and great customer service, it will also depend on a large number of external factors: confidence in public cloud infrastructure, viral effects around cloud-based deployment, messaging and investment of the leading software vendors towards the cloud, adoption of SaaS solutions, type of new applications being deployed, growth of the mobile applications market, (reduced-)IT spending, world’s economy, etc.

Consequently, the right thing we can do at CloudBees is to keep innovating, flawlessly deliver on quality releases and top service and aim for the long term. More of the same essentially.

To that end, we had in mind to raise a second round of funding later this year. That was the plan at least. It was without counting on a high-energy and talented investor, John Vrionis from Lightspeed Venture Partners who pinged me some time ago: he told me he had essentially done a lot of research, carefully studied this market, and he wanted to be part of the CloudBees adventure. He liked the market, the team, the approach and thought we needed to be equipped to do what is right for the company, resource-wise and time-wise.

As we got to know each other better, we obviously performed our due-diligence and checked on John’s references. My dream is that if 10 years from now I get reference checked, I would like to get 10% of the positive feedback that John got. We were looking for a West Coast VC that would not merely sit on the board but would be part of the team, dedicate time, energy, frustration, joy and neurons to CloudBees and obviously understand what’s happening in the cloud.

Welcome John.


Sacha Labourey, CEO
Follow CloudBees:
Facebook Twitter

Friday, July 22, 2011

6 Major Differences Between Jenkins and Nectar

Blog author: Nicolas De Loof, CloudBees
CloudBees Nectar is an enterprise-level, customized version of open source Jenkins. Nectar and Jenkins share the same code base, but Nectar has a distinct release cycle. CloudBees releases a major Nectar version every six months, with long term (18 month) support and backward compatible bug fixes. The release builds on top of Jenkins with additional testing of the CloudBees plugins. Select bug fixes from open source Jenkins are back-ported to Nectar during the support period. Nectar subscribers also receive patches every six weeks. This predictable cadence of patches for critical issues provides a mechanism for organizations to maintain a stable Nectar installation. With Nectar, an enterprise can build its software factory with a robust, reliable, and well-supported continuous integration server.

Nectar also provides enterprise-level features as custom plugins, such as role based access control (RBAC), hierarchical folders to organize jobs on large c.i. servers, VMware ESXi auto-scaling, advanced backup scheduling, throttled build execution on virtual machines, and Wikitext description. 

Let’s briefly explore each of these plugins:

Role Based Access Control (RBAC)
Nectar administrators can define roles (a set of permissions) and let project team leaders give developers appropriate roles. Compared to standard access control, which requires an administrator to review a large set of checkboxes for each user, or to LDAP / Active Directory integration that requires definition of fine grained c.i. permissions in a centralized directory, the RBAC plugin allows access management to be configured in a more concise and productive way. The RBAC plugin is one of the most sophisticated authorization plugins on the market.

Hierarchical Folders to Organize Jobs on Large C.I. Servers
Some c.i. servers host hundreds or even thousands of jobs. In such instances, organizing jobs is a requirement for usability. The folder plugin allows you to group jobs into hierarchical folders, and manage them as a unique item, as you already do with filesystem folders. Cloning folders or defining folder-level properties allows you to simplify workflow management on code branching. 

VMware ESXi Auto-Scaling
On VMware infrastructure, this plugin allows you to assign VMs to the software factory as c.i. slaves. You can configure within your infrastructure a set of VMs, all being identical (not dedicated to a job). The VMware plugin will then pool those VMs, and associate them to jobs that require a VM during build. The plugin can control the VM state, power-on VM before being used by a job and power-off after use, but also revert to a previous snapshot state. This is useful when such VMs are setup with the enterprise standard Java platform configuration. Each build will then get a clean, standardized VM.

Advanced Backup Scheduling
When c.i. is the center of your workflow, backing it up becomes a crucial task. The advanced backup plugin allows you to manage backups directly from Nectar, and especially to fine-grained define what needs to get backed up: only jobs configuration, also recorded build results, or system configuration - including installed plugins. The plugin also allows you to define the backup target, as a dedicated backup directory or an SCP server. 

Throttled Build Execution on Virtual Machines
With virtualization, we get used to creating more and more VMs, expecting the hypervisor to balance physical resources. When we define 10 slave VMs for a c.i. server with 2 executors each, the underlying virtualized system may not be able to run more than 8 in parallel, depending on its physical resources. Defining more VMs will only create more context switch and swap, and make the whole system less efficient. The Nectar plugin allows you to define the physical limit to a group of slaves that you know will run on the same physical system. You can then define as many slave VMs as needed with various configurations (for example, to test your application on various OS in a matrix job) but not overload the hypervisor.

User Friendly Wikitext Descriptions
In open source Jenkins, descriptions are written in raw HTML. This is not really pleasant to write and can introduce XSS vulnerability. Wikitext allows you to switch editors to a Wiki syntax that is more intuitive to write and limits the set of HTML tags in descriptions to safe formatting-only ones.

For more information on the plug-ins discussed in this blog, including short videos and examples, visit:

- Nicolas de Loof

Follow CloudBees:
Facebook Twitter

Wednesday, July 13, 2011

CloudBees Webinar: Authentication and Authorization in Jenkins on July 27th

One of the most-often asked questions we get about Jenkins is, "How do I put the right authorization mechanisms in place for securing Jenkins?"

There is usually an implied question in there, which is, "Which authentication plugin should I be looking at and how do I set it up?"

Our next webinar focuses on the Authentication and Authorization plugins available to Jenkins users. Jenkins veteran developer Stephen Connolly will...

  • Look into the top authentication plugins like "Active Directory", "Crowd", and "Unix password".

  • Dive into authorization plugins like the "Role Strategy" plugin and others.

  • Showcase Nectar's Role-based Access Control plugin (Nectar is CloudBees' pro version of Jenkins).
    This plugin has been the most often requested feature for CloudBees as it provides users a higher level of sophistication that is not available in the open source plugins.

He will wrap up with some use-cases, walk-throughs and Q&A.

This webinar is a followup to Kohsuke's "Securing Jenkins" webinar that we did in March. You can view that webinar here.

Who is Stephen?
Stephen is an awesome guy who happens to be one of the top committers to the Jenkins project and is on the Maven PMC. Here is a link to his bio on CloudBees. I could point you to his LinkedIn bio but then I run the risk that you may try to hire him ;-).

Sign up Information:
When: July 27th, 9 am PT / noon ET


If you are busy, sign up nevertheless as we will send a video of the recording and slides.
- Harpreet Singh, Senior Director of Product Management

Follow CloudBees:
Facebook Twitter

NoSQL: CouchDB with CloudBees and Cloudant

(WARNING: this blog is a bit of a tutorial, so feel free to let your eyes glaze over if it gets boring - it will show how easy it is to use partner services to build applications, in this case a NoSQL database.)

In this tutorial I will build a CouchDB based url shortener service ( using CloudBees and the services/add-on platform with Cloudant.

CouchDB is a popular NoSQL database - specifically you could called it a "document database" - i.e. it is all about storing documents which consist of sets of fields in a JSON document against a key. There is no schema - a document can consist of any JSON structure - there is no requirement that the same fields be present in each document unlike rows in a RDBMS. Of course CouchDB has a lot of the other benefits of NoSQL databases - high scalability and ease of use.

Cloudant provides an excellent hosted CouchDB service. This takes care of *all* the management of CouchDB you would normally need to do - compaction, backups, and more.

Building a URL shortener

A url shortener is just that - takes a long messy URL and generates a token/shorter URL you can pass around.

Step 1: Get a account, signup to a free RUN@cloud service.

Step 2: Go to - and choose Cloudant.

Step 3: Create a new web app skeleton.

For this I will use the Play! Framework - a simple framework for building RESTful web apps. I can use the command

play new urlshort --with scala

This will create an empty project using scala. To deploy to cloudbees - a handy way is to add cloudbees 0.2.1 to the dependencies file (don't worry - source repo will be available to look at).

Step 4: Create an empty database.

From - you can navigate to your Cloudant/CouchDB console. Any time you need to get back to the CouchDB console you can navigate from grandcentral.

This shows the "Futon" web interface to browse your data, quite a handy tool. Here you can create a new database - I called mine "urly". Once you have a database, at the top left corner you can see an icon which will take you to the Cloudant management screen - click through to the newly created database, and you will be able to set permissions, and generate an api key:

The important bit is to note the api key details (a user name and password that you will use in your app). The user just generated should also get read/write access to your database (set it with the checkboxes).

Step 5: Set up credentials in your application config.

In this case, as I am using the Play! framework - the configuration is in application.conf. The keys I set up were:

#CloudBees details
bees.api.key= key for deploying
bees.api.secret= secret for deploying

#Cloudant details
couch.user=api key user
couch.password=api key password

I put the CloudBees details in there for easy deployment but technically you don't have to (you can pass them to command line if you like).

Step 6: Talking to CouchDB

One of the really nice things about CouchDB is that you don't need any drivers or dependencies to talk to it - https is a "native" api for it. So all that is needed is a simple http/REST/WS client.

Urls are how you address content - you can store a document in a nominated key for example by PUT'ing a JSON body to (urly is the name of the database). Updates to data require you to specify the current version tag of the data (field in the JSON body) as a form of optimistic locking.

Getting the data back is a simple GET ! (obviously there is a lot more you can read about if you need). In this case - the keys are the randomly generated "slugs" that form the short URL.

Step 7: Wire up the application.

Descending from the mountain top, a simple codebase which generates random url "slugs" and then does appropriate http redirects was carved in stone (also here here

Authentication with CouchDB is using http basic over SSL (using the api keys mentioned earlier).

Step 8: Deploy.

(This will use the Play! CloudBees plugin - thanks Ivan !)

I then set up a domain and a record pointing to the host for the app, running at

Note that there was no need to migrate any data, or setup a schema (just create the database by name - which I could have also done programmatically).

The data is safely stored in CouchDB (below is browsing it with Futon):

Map Reduce and views

A further enhancement is to create views. CouchDB uses a Map Reduce model to provide views and aggregate calculations.

A view is similar to what relational databases offer and only requires a map function to be provided. Reducing is a more complicated topic and I won't show it, but it could be used, for example, to calculate aggregates (sum or average over some range of documents). The advantage of a Map Reduce model is that the calculation can be distributed and run in parallel with the data - good for very large sets of data.

The Map function above simply takes a document and emits another document which is made up of the slug and the agent string (each browser provides an agent string). The key in this case is the url we stored - this means we can (if we want) lookup slugs based on URL (the reverse of what we were doing before). Note that as the fields in each document are optional - even if there is no agent field the above view will still work (just will have no agent field in the view output).

The functions are written in javascript - and are themselves stored as documents (with a special naming convention). The results of these views are accessed the same as the normal documents you write data to.

Hopefully from this you get a taste of the convenience and power of CouchDB and Cloudant.

You can sign up for both CloudBees (if you don't have an account) and the Cloudant service here:

-- Michael Neale, Elite Developer and Architect

Follow CloudBees:
Facebook Twitter

Friday, July 8, 2011

CloudBees Toolkit for Eclipse: Bringing the Cloud to Eclipse Developers

As a Java developer, you want to turn code around as quickly as possible, and you work hard to eliminate roadblocks and unnecessary work. Java developers everywhere are also trying to figure out - how they can take advantage of the cloud and bring that power to their apps or development.
As you write or update a piece of code, you may get frustrated when build deployment steps slow down the development process. Builds take time to setup, manage and monitor. Applications are difficult to provision or can't scale. You can't move as quickly as you need to.
Today CloudBees is proud to announce the GA of our new Eclipse toolkit, which streamlines builds and deployments by providing Java developers with the fastest Eclipse-to-the-cloud path anywhere. Now you can manage your entire development-build-deployment lifecycle in the cloud without ever leaving your Eclipse IDE.
Want Jenkins in Eclipse?
CloudBees' DEV@cloud service provides the continuous integration capabilities of "Jenkins as a Service" in the cloud, along with SVN and Git source code repositories and Maven repositories for builds. The Eclipse toolkit connects DEV@cloud directly to Eclipse, so you can create and monitor Jenkins jobs running on CloudBees inside Eclipse. [Try it yourself! Just point to from within Eclipse and install
the plugin.]

How about One-Click Cloud Deployment in Eclipse?
On the deployment side, CloudBees' RUN@cloud Platform as a Service lets you quickly and easily deploy Java applications to the cloud -- without purchasing, configuring and maintaining hardware, and without programming applications for a specific underlying infrastructure service (IaaS). Just configure once, then take advantage of one-click deployment that is super quick due to the automatic incremental upload feature (we just upload the changes, not the entire project). Your apps automatically have full support for Security, SSL, Automatic Scale DUO (Down, Up and Out), Clustering, and session replication. And you don't have to lose time on painful negotiations with IT or DevOps to get your applications deployed, managed, and updated.
Support for both on premise and cloud builds and deployments
In addition to monitoring Jenkins builds on CloudBees, you can use the Eclipse plug-in to connect to your existing on-premise Jenkins jobs. So you won't need to fire up a browser to view the status of your builds. You just write code, push it to Jenkins and observe build status right through Eclipse.
With the CloudBees Eclipse toolkit, you can choose to either run in a local environment or you can deploy to the CloudBees RUN@cloud PaaS. If you want to deploy locally for easy application testing, it's as easy as saying "run as" on a local instance. Once you've tested your application and are ready to push it out to the cloud, just push a button in Eclipse to deploy it to RUN@cloud.
Now you have a choice in where you build and deploy, so you can transition to the cloud gradually, at whatever pace works best for you.
So, back to productivity...
The new Eclipse toolkit is yet another step in CloudBees' march to help you accelerate and streamline the process of developing and deploying Java applications in the cloud. You will save time with... One click access to Jenkins builds in the Eclipse window
  • Almost immediate feedback on your code changes - you'll know right away when the build breaks
  • Build and test environments that scale up or down as required by your project, without manual adjustments from you or other teams
  • Automated deployment of applications in the cloud
With CloudBees, you're free to focus on your most important priority: writing high-quality code and getting it to market fast! Give it a try - it's free. Once you have an account, just point to from within Eclipse and get started -- you can be up and running with Jenkins and automated deployment inside Eclipse very quickly.
-- Harpreet
Learn about fastest path from Eclipse to the Cloud:

Follow CloudBees:
Facebook Twitter

Wednesday, July 6, 2011

Five Reasons Why Developers Choose Jenkins Over Hudson for Continuous Integration

A quick history lesson -- Jenkins, previously known as Hudson, is an open source continuous integration tool written in Java. Last November concern arose in the community around Oracle's perceived control of the Hudson project (including the name itself, for which Oracle submitted a trademark in December 2010). In early 2011, the community proposed and ultimately approved renaming the code to Jenkins and continue development on the tool, leaving Oracle in control of the original Hudson code. Oracle responded in February by announcing their commitment to continue their own development of Hudson, and in May, submitted a proposal to the Eclipse Foundation to create a Hudson project in Eclipse.

So, now that there are two continuous integration tools written in Java, why should a developer choose one over the other? Below are five reasons to choose Jenkins.

1. Led by developers for developers
First and foremost, the developers who wrote 99% of the core of Hudson are now working on Jenkins, including Kohsuke Kawaguchi, the original creator. He wrote the majority of code single-handedly and his range of expertise was a key enabler in various advanced features of Hudson. Currently, Jenkins has all but one original Hudson committer on its side (48 different people have submitted commits since the split) and there's been a significant increase in overall contributions. To date there have been:
    - 733 total commits (compared to 172 previously)
    - 170 pull requests (compared to 20 previously)
    - 94 publicized committers on GitHub (compared to 4 previously)
    - 496 repositories (compared to 1 previously)

2. Governance and Community
The community managing the Jenkins project is very open. There is an independent board that includes long time Hudson developers from multiple companies including Yahoo!, CloudBees, Cloudera and Apture. They hold regular governance meetings and post notes after each meeting for public comment. They're also donating all the code to Software in the Public Interest (SPI) to assure continued openness of the community.

3. Stability
As we see the increase in the contributions to Jenkins, more than 280 tickets have closed since the split, and Jenkins has started a new long-term support release line. The community has decided to announce a stable release approximately every three months with patches. Lastly, Jenkins posted its first release 1.409.1, which provides a more conservative and slower upgrade path to organizations.

4. Jenkins is the primary platform for plug-Ins
Jenkins currently supports 392 plug-ins. Of the top 25 plug-ins, 21 moved to Jenkins and four had no commits. Plus, there have been 40 new plug-ins since the split. With such powerful and diverse functionality, Jenkins is the hub of the new application development lifecycle.

5. Jenkins is cloud-enabled
One of the core needs of Jenkins users is the lack of resources during peak periods. CloudBees provides a solution with DEV@cloud, providing developers with Jenkins build, test, and packaging services as well as unlimited, pay-as-you-go scalability with no need to configure and maintain their own build servers.

In addition to all of the above, you shouldn't hesitate to upgrade because you're concerned it will be an effort - it's very easy to do. You can literally be up and running in less than four minutes! Also, CloudBees offers a commercial version of Jenkins, Nectar, which you can try for free! Finally, if you’d like to learn more about Jenkins, we plan on having a Jenkins newsletter in the future but until then you can sign up for our company newsletter. You might enjoy Kohsuke's "7 Ways to Optimize Jenkins" whitepaper.

Reminder: Jenkins training will be taught by Kohsuke on July 14 in NYC and again in the Bay Area on August 16 - don’t miss it!

(Full disclosure: Kohsuke Kawaguchi, the creator of the original Hudson project, works as an elite developer and architect at CloudBees and is on the Jenkins governance board).

Follow CloudBees:
Facebook Twitter

Tuesday, July 5, 2011

Upcoming Jenkins Training in New York

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!

- Kohsuke Kawaguchi