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.
For more information on package repositories, view our on-demand best practices lesson: 'The Role of Binary Repositories in SCM'
That ALMOST looks like nail. Doesn't it? Image courtesy of Justin Baeder
In 1966 Abraham Maslow said, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” Maslow gave us all too much credit. When we have a hammer and know how great it is, we not only treat everything as a nail, we actually perceive everything to be a nail. One develops a blindness to “non-nail” problems and creative problem solving takes a back seat to picking up that hammer and smashing the problem.
For those of us in the tool-making business, this blindness can be our greatest weakness. We know our tools extremely well, and know how to bend them to purposes outside their sweet-spot. When Continue reading
We’re often asked where to start when organizations want to standardize their deployment processes across environments. Starting with the deployment to development environments is common. Developers extend their continuous integration platforms towards continuous delivery organically, deploying to dev test environments for simple functional tests. And later to QA environments using similar approaches.
Many of these organic efforts stumble when they get closer to production. The production deployment often differs so much from the development deployments that the automation can’t be tweaked to meet the challenge. Common tripping points include the inclusion of clusters, load balancers, backups and databases (where dropping all the tables isn’t an option in production). This is so common that most continuous delivery efforts stop at a test environment and aren’t used for staging, production or disaster recovery environments.
Having seen teams reach this stumbling block over and over again, I’m increasingly convinced that for a common process to be created, you have to start with the production deployment process and work backwards from there. For databases, that means that development deployments should use incremental updates to databases rather than a drop and recreate approach. Having a load balancer in QA would be nice, but if it isn’t present, the automation should have a switch in it for, “If there’s a load balancer….” otherwise skip this part of the deployment.
Essentially, the goal is to move from a situation where dev and production deployments are “different” to one where the dev deployment is treated as a simpler version (a subset) of the production deployment. Once a common process is agreed upon (even if its just on paper at this point) standardization and automation efforts can begin in earnest with a good chance of success.
Vast majority of daily practitioners of Continuous Integration don’t really understand it. This is a bold statement, I know. But it is not made to simply capture attention. Most practitioners of Continuous Integration, when asked, will either tell you that CI is about integrating changes often, or that it’s about producing frequent builds of your software. Both these answers are incomplete at best. Even articles on Continuous Integration gloss over the thinking behind it and jump straight to the implementation.
So this blog entry is about the “thinking” behind Continuous Integration. Because only by understanding the core ideas behind CI can you understand what is happening in the industry now or get a glimpse of where it is headed in the future. Once you “get” the core concepts behind CI, it’s easy to see that Continuous Delivery is a natural extension of Continuous Integration. Continue reading
As build lifecycle automation has expanded beyond build and unit test and moved into deployments, promotions, and releases over the last few years, a number of terms have popped up to describe what people are doing. We hear about Enterprise Continuous Integration, Continuous Deployment, DevOps, Build Pipelines and more. This article takes a quick look at the various terms, and what each one means and where its proponents put their focus.
“Plain old” continuous integration
In standard CI, we see developers working on shared code lines frequently integrating their work and an automated build system testing those commits through frequent build and unit test . This type of CI is in many ways the father of the end to end automation we see today.
Enterprise Continuous Integration
Where basic continuous integration is a team level effort, enterprise CI cuts across teams. Enterprise Continuous Integration manages and automates the processes between build and eventual release to production or to customers. Likewise, more than a single development team or department is likely to work within a single ECI interface. The benefits of visibility and repeatability and efficiency through automation that CI provided a single team are now shared through the Enterprise. Continue reading