We include a built in package repository, CodeStation, with AnthillPro, uBuild and uDeploy. They also integrate with third party repos. We place much emphasis on this capability because it is critical for safety, governance and audit.
To explain this, let’s first look at a simplified build and release lifecycle:
Developers submit their work to a source control system. A build is generated from that source and any dependency libraries retrieved by a tool like Maven or CodeStation. That build is submitted to test environments and certified. Finally, it is sent to production.
The following questions are important to be able to answer:
What is in production?
Was it certified in test environments (and by whom)?
How do you know your answers to #1 and #2 are true?
To be able to answer 1 and 2, you need an inventory of what version of something is in an environment or at least logging that indicates the version number. But to truly know that what is in production is what was tested, you have to ensure that not just are the file names the same, but that the exact same files were moved into each environment.
In order to know and prove that the files are the same, one must validate that they are bit-for-bit identical by comparing digital signatures or hashes at deployment time. It helps to actually have the original file around in a tamper resistant location. A good package repository, like the one in uDeploy, will provide that location, the automatic signature generation at build time, and the automatic verification so that you know that what is in production is exactly what was built from known source, and tested in the prior environments.
While I can not take the credit for coming up with Continuous Integration (it can be traced back to timeless practices) or for even coining the term, I can take the credit for creating one of the first Open Source (later turned commercial) CI servers — Anthill, released in July of 2001. That has given me an almost unique vantage point for watching the evolution of CI and seeing it take the industry by storm. One of the most interesting phenomenon I have come across was seeing our customers use AnthillPro (back when it had build only functionality) to automate deployments back in 2004. Keep in mind that this was back in the days before the term Continuous Delivery was coined. At first it seemed to me that the wrong tool was being used for the job. But then I realized that the features present in any implementation of CI really advanced Automation from the invention stage to the innovation stage. Continue reading →
I recently visited a customer and was surprised to learn just how sophisticated their IT operation is. They have a private cloud for Dev and Test and automated deployments (courtesy of AnthillPro) across all environments. The development and QA teams may request an environment for a specified period of time and then deploy their build to this environment for testing. This entire system, the environment provisioning and the application deployment is fully automated and turns what used to be a multi-week process into a one that literally takes minutes. BTW, these environments are non trivial as they are made up of multiple virtual machines along with network configuration, firewall rules, load balancing, edge caching, and more. Continue reading →
Last week I was updating our website. I made some changes locally and committed them. A few minutes later, I was back at my desk after refreshing my coffee and immediately was concerned. My instant message client was not blinking as it should be. Where was my “build complete” notification? Where was the notification of deployment to test?
Concerned, I logged into AnthillPro and checked current activity. My build had just started, and there was a bit of a queue. No big deal, I was notified a few minutes later of completion. When the same thing happened the next day, I started to get curious since usually our build farm has plenty of capacity and queuing is rare. I checked the metrics. 10,000 builds in the last month. An average week day saw 400+ builds. I knew we were doing more and more, but that’s a crazy number. In simple CI where each commit triggers one build and each developer is committing about twice a day, 10k builds would be appropriate for 200 developers. We have less than that. Continue reading →
A common build scenario is to need to compile on several different platforms. The basic build is all the same, but a couple parameters change platform to platform. Here we look at the basics of configuring this kind of scenario in AnthillPro.
A build job that is parameterized
A workflow that iterates over that build job for each platform
An agent filter that directs each iteration to the appropriate platform
Properties on the iteration that are the build job parameters and inform the filter