Late lifecycle builds

Building in a non-originating workflow

Our early experiences configuring AnthillPro teach us that builds are done by "originating" workflows and deployments, tests, and all that good post-build stuff tends to happen in "non-originating" workflows. This makes good sense. We start by doing a build, and then can come back to that build later and do things to it. This is a good lesson, but like Newtonian physics it can break down when things get interesting.

Things get interesting

Let's look at a couple  scenarios that might induce us to want to do additional builds or introduce additional build types. The the first is static analysis. There are any number of tools out there that examine your source code and report on possible defects, failure to apply coding standards, or likely security vulnerabilities. Consider Fortify SCA, PMD, Lint or jTest and others. Many of these tools take a long time to process the source code. Testing every continuous integration build may be overkill that lengthens builds unnecessarily, but scanning nightly or scanning a production candidate may be more attractive.

Another interesting situation is instrumented code. Again, many tools seek to embed extra tracing information in your compiled code to perform analysis. This can be for code-coverage, tracking memory allocation, or checking run-time security. Often times though, the added instrumentation causes a loss of performance or code obfuscation. This may be acceptable in testing, but not in production. This leaves us desiring a separate type of build for these tests, but still wanting a way to link that to our releases.

So, there's the challenge. We either want instrumented builds tied to our actual, deployable builds or we want to circle back and scan the source for a build. Both needs could be met by zipping up our source code and publishing it as an artifact. We could expand it out later and scan it, or do an instrumented build from it. But that source code is already stored somewhere (your source control system) so that's wasteful. Let's do better.

Finding the source

So if we do want to just get the source code again from source control, we then have to figure out how to make Anthill go do that. Fortunately, for most source control systems, this is remarkably easy. For most source control systems you just run the populate workspace step again. You may ask, "But doesn't that get the latest?" Not really, it usually does a code fetch based on a "workspace date" - go check a build job and you'll find this strange property in the top right. So most check-outs are based on a date time stamp that roughly aligns with the build trigger. Conveniently, this information is stored and if you rerun the checkout for a build life that is a week old, you'll get the code from some branch as it was a week ago. It's such a perfect fit, I wish we could claim we put it in for this purpose - but it's a happy accident.

Building Again

Great, we have determined that we want to build again, and we can get the same source code out. Do we need a second job? We probably do. The current build job could work, but we likely don't want to use the same statuses (or any) for success and failure and want to use different artifact delivery rules - probably no artifact delivery for static analysis and delivery to an alternate artifact set for instrumented code.

But otherwise, our build job will likely remain fairly similar with some additional reports. This will link in the reports from instrumented or analyzed code with all the other reports about our build as it goes through varies testing environments and promotions. It also prevents us from having multiple build types to contend with and have multiply as we branch. Overall, it's a pretty simple, if non-obvious technique, to link other build approaches with our living builds.