CloudBees Flow DevOps Automation Platform Best Practices: 2015 Update

At our user conference two years ago, our own Noel Seaton presented on best practices for ElectricCommander - which is the automation platform now underlying our CloudBees Flow solution. The presentation was so well received that we have included it in our Training material. So roughly a year and half later, I wanted to touch base with our CloudBees Flow customers and share some of my recent experiences with your favorite automation platform, and some best practices you may want to incorporate into your daily operations.

5.x upgrade

If you have not upgraded to our latest Long Term Support release (LTS) version 5.0.3 or one of our feature releases (5.1, 5.2 or 5.3), I would strongly suggest that you start educating yourself with the work required for the upgrade. The main change is that the jobId is now a Universal Unique Identifier (UUID) which is represented by a 32-character string, previously it was an integer. Details on the upgrade can be found in the Installation Guide . We recommend that you change your job and workflow name templates to use an auto-incremented global counter per project. We even provide a script to help you with this. However if you use a jobId (or workflowId) in places other than your job name and workflow name templates, such as to compare objects, retrieve artifacts, … you will have to modify your code manually as 32 bit uuid are not comparable for order. A lot of that work can be done on your current 4.x test server so the earlier you start, the better your transition will be.

Backup

I still encounter many customers without a serious backup plan. So please go back to my original article on the subject if this is still your case. EC-Admin has a few new procedures to help you there, and it can be found on our github site. Trust me, you will thank me one day to have a multilevel backup strategy. Also, snapshots are a great feature of virtual environment. I encourage you to use them if you are using Virtual environments, before any major change (like an upgrade).

Plugins and Projects

Some of you are using plugins to help keep track of project version you installed in Production after developing it and testing on your “Dev” server. I hope you use Agile and CI principles for your development of plugins and automation procedures, and that you do not push anything new to your “Prod” server without testing. We published our own test framework to help you with that. One of the side effects of installing a plugin and simply modifying only the minor version or build number (third or fourth number) is that the new version overwrites the previous version. And like for any normal project, when it is deleted, the attached jobs are deleted as well. If you want to preserve them, you have several options:

1. Modify only the first or second digit of a plugin so it keeps the older versions and therefore preserving the associated jobs.

2. Write some code in ec_setup.pl to preserve those jobs upon promotion. The “moveJobs() ” API may be handy for that.

3. Use the new option in EC-Admin to do that automatically.

Separate Code and Data

One of the greatest pains I see when users of the CloudBees Flow automation platform (ElectricCommander) move a project from Dev to Prod is the management of the data. Typically, when procedures are created, a bunch of properties are attached to the same project. So what happens when those properties are different in the Dev and Prod environment? Let’s consider some examples: A service port : you can work around the problem by attaching the matching property to a resource or a resource pool. A buildId: if this property is attached to the project itself and you update a new version to production, you will lose the current value and replace it with the Dev one. In doing so, you lose data and take the risk of some job name getting duplicated, and therefore fail you run. Consider attaching your buildId/jobCounters to /server/<projectName> instead. What about generic properties like a list of products, addresses to send emails, ….? Those have usually different values in Dev and Prod and you do not want to have to modify all of those when you push a new version of your plugin or project to Prod. You could write a procedure to do that but there is always a risk you might miss some or forget to run the procedure altogether. My advice is to separate the code and data. The code includes your procedures, properties containing code, notifiers (be sure to use properties for the “To” field to differentiate between Dev and Prod) … The data includes properties and potentially your schedules as they may take different parameters and frequency on each servers.

I hope those few recommendations make sense for you. Please let me know if you have other you’d like to share by leaving a comment below.