Source Control Systems provide mechanisms for keeping track of every change to your application source code. Identifying which changes have been deployed to which environments is either managed by deployment tooling, manual process, or in many cases, not managed at all. In today’s world of regulations and audits, leaving this unmanaged in not an option. Among other things, auditors will require reconciliation of what the source code changes were, who made them, and when they were deployed to production. Who made the source code changes, and when, is managed natively by the SCM, but when they were applied to production is not. Capturing which revisions of the source code are applied to which environment will need to be tracked by manual process or using other tooling.
Like any Application Release Automation (ARA) solution, FlexDeploy has features which allow you to build and deploy source code into environments, and maintains the metadata which can be used to satisfy internal and external auditors. The reconciliation between the SCM and ARA metadata is used to provide this information.
One technique for minimizing the effort in the reconciliation process is to store the ARA metadata in the SCM itself, making the reconciliation process even easier. In this blog I will highlight this technique using FlexDeploy and Subversion. The idea is that the source code for every build and deployment is recorded in Subversion using tags. Without automation in place, creating these tags would be an overhead and likely not worth the effort. And that is where FlexDeploy comes in.
Consider the following Subversion structure representing a Java application.
<Repo>/HumanResources/WorkBetterFaces/trunk/….
When we build the application FlexDeploy will version its EAR artifact (1.0, 1.1, 1.2 etc.). To associate the source code used to build that artifact we will tag the source code using the same versioning scheme.
<Repo>/HumanResources/WorkBetterFaces/tags/Builds/1.0/….
When we deploy to an environment we will tag the same source with a tag representing its version and the environment it was deployed to.
<Repo>/HumanResources/WorkBetterFaces/tags/Deployments/PROD/1.0/…
With this tagging scheme we have full lineage of the source code (for every commit) across the build and deployment lifecycle. It is easy to answer questions such as “What version of the source code is deployed to production?” and “Does the source code in UAT match that of Production?”. And these questions can be answered within the SCM itself.
Depending on the size of the release and the number of applications/projects involved, the number of builds and deployments across all environments can easily grow into the hundreds. So it’s quite obvious that we wouldn’t want to create these tags manually with every single build and deployment. Using FlexDeploy we can create these tags systematically with simple project configuration and two workflow steps (one in the build workflow, and one in the deploy workflow).
The project configuration is adjusted to account for the tagging scheme we will use during the build phase.
The build workflow simply uses the tagProjectSources operation from the Subverison plugin. This operation will use the Tag Path Script of the project (shown above) to generate the path used to tag the source code which we are building.
The deploy workflow uses the copy operation from the Subversion plugin to tag the source code during deployment.
The configuration of the copy step utilizes Groovy expressions and FlexDeploy Properties to perform the tagging operation. The available properties and their values can be viewed within the execution of the build and deploy workflows.
That’s all there is to it. I executed a few builds of the WorkBetter project and deployed them to DEV, QA, and PROD. Using the TortoiseSVN revision graph, we can visualize the lineage.
All of the tagging was managed automatically, making it repeatable and reliable, achieving source code lineage across the build and deployment lifecycle. Dread audits no more!