For Audit, control the binaries

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:

 

Code, then build, then deploy to test environments, then deploy to production. 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:

  1. What is in production?
  2. Was it certified in test environments (and by whom)?
  3. 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'

What’s the Difference: CI vs Build Management?

I was recently brought into a conversation about continuous integration and build management. The questions were predictable: What’s the difference? Are they the same thing? They’re both kinda about build, right?

The two efforts are quite different. However, in practice, the steps taken to achieve them overlap significantly.

Build Management Build management controls what goes into a build, creating a bill of materials, and then tracks that build from creation to go-live.

Continuous Integration: Is a practice of developers committing frequently to a common code line which is supported by aggressively testing the resulting software to verify that it’s getting better, not worse. Maciej Zawadzki expands on the quality emphasis of continuous integration here.

Diverging Goals , Similar Automation

We have these two ideas which on paper have almost nothing to do with one another. Then we look at how you might accomplish each with automation. For build management, you would have rules that would determine your source and dependency inputs. Automation would execute the formal build process and store the output files (artifacts) somewhere safe and traceable. For continuous integration, you would also have rules for defining what to build, then run the build, and some tests. If CI is extended to functional testing, you would need to manage the built files so that they can be deployed somewhere for testing. That’s a lot of overlap.

What happened is that early CI tools and early automated build management tools had such similar feature sets that the market identified them as competitors. Competitive pressure helped merge the feature sets so that most CI tools today (and any tool that effectively does continuous delivery), also provide build management to one degree or another.

For more on the difference between build management and continuous integration, see our white-paper Drawing the Line: Continuous Integration and Build Management

Yikes! Anthill is big, where do I start?

I’ve had the privilege of working closely with a number of customers to help them get up and started quickly. I also keep an eye on our support traffic. In both cases, I see new Anthill users who are impressed with the tool, but a little unsure about where to start.

Start Fast, Be Happy

I believe in immediate gratification, so the first place to start is to get your project building. The Simple Project Configurationtutorial is a great place to start. By following the example there, you should have your project up and building pretty quickly.  Continue reading