Yet Another Automatic Release

In the last quarter, we have moved many more of our integration projects to GitHub as public projects. Less visibly, we have also made big improvements to our build process using Jenkins. In addition to compiling, testing, and packaging, we have also automated many of the steps for release in a build promotion. Specifically, we automated publishing of a new application catalog entry, pushing the integration package to Amazon S3, and tagging of the GitHub repository.

This new automation really paid off a couple days ago. A customer reported they had downloaded the VersionOne Provisioning Tool for LDAP but did not find any executable inside. In migrating this project, we had hooked up the packaging step incorrectly. The fix was quick enough but, prior to migration, it would have taken a lot of manual effort to get the new release out the door, with at least a day until the new bits were available. This time, it took less than 2 hours from when I learned about the problem, to when it was available for download.

As if fast turn around weren’t enough benefit, I have also noticed that taking the time to automate these steps has brought much more consistency across the two dozen odd projects we maintain. That makes it easier to ramp up new people on the code, and makes it easier for our support team to diagnose issues.

Our release process isn’t quite DevOps since we are just posting a zip, leaving the work of actual deployment in the hands of customers. However, it is still a good step in the right direction. If there are any customers who want to take the next step toward DevOps with us, let me know. It would be good to put more automation around the deployment of the integrations.

This entry was posted in Our Practices. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *