DevOps practices
DevOps is an amalgamation of interesting ingredients of process, people and then tool. Baselining a process that is workable is pivotal to success of process. This leads to many enterprise-wide practices and culture. To this if you add people each have their own interpretation and approach to solve problem. This might at first look as complete chaos reigning on the enterprise but it has an implicit order to it. The order of aligning with folk culture of the specific enterprise. Thus, we sometimes find it very tricky and challenging to explain a single best practice for DevOps. The last ingredient though might sound interesting for nerds it is mostly driven by the first two and the ritual of selecting a tool is dominantly straight forward process if you solve the difficult ones like process and people.
In recent technology governance connects, we discovered divergence of thoughts amongst various development teams on how application is deployed in other words promoted to higher environments. The divergence point was the should code be promoted or should application binaries be promoted. There are finer prints when we say application binaries; like – Is it only the application binaries or is it with the runtime environment or is it with the entire technology stack like docker.
In our initial futile attempt, we took this path; We asked the teams show their pipeline definitions and were trying to decipher if we could decide was there any inherent flaws or merits to the approach. This was futile as within few minutes of inspection we noted teams going defensive in defending their approach of application deployment promotion. This kind of defensive environment blocked any interesting thoughts and deliberations. Indeed, people and process are the pivotal lever. For technology organisations there can be multiple true and workable processes based on the environment of their delivery and the nature of challenge they are solving. If you are wondering how did both pipelines, we will still put that on table and talk about both.
There are two types of pipelines both teams used nearly similar process –
This was helpful as there was no fundamental divergence. From a practice perspective you might consult to have continuous integration for quality control and demo environment too, but practically it is always approval driven and gated at best. For most part of enterprise, it is always a point in time when some human decides to have the application move up the hierarchy.
Towards this, the pipeline (Azure DevOps service Pipeline YAML definition) for develop environment looks like this –
|
trigger: – main
pool: vmImage: ubuntu-latest
variables: buildConfiguration: ‘Release’
steps: – task: Docker@2 displayName: ‘Publish docker image’ inputs: containerRegistry: ‘ev-optimizer’ repository: ‘frontend’ command: ‘buildAndPush‘ Dockerfile: ‘**/Dockerfile‘
|
Since the teams were using docker, it was fairly simple with the activity of building the docker file. The interesting part might the trigger which watches any change in the main branch. Operationally there are few nuances like the task Docker@2 will require active service connection to a docker registry but we will not dive in how that is to be accomplished.
The interesting part was what came next and the reason for this article. The pipeline for the test environment looked like this for the team that believed in code promotions –
|
trigger: – test
pool: vmImage: ubuntu-latest
variables: buildConfiguration: ‘Release’
steps: – task: Docker@2 displayName: ‘Publish docker image’ …
|
This is similar to the pipeline for the develop environment and has CI disabled outside the YAML. This requires that someone has created the branch test and pushes code regularly in a controlled manner. We will pick up more the emphasis on controlled manner little latter in this article.
The pipeline for the team that believed in binary image-based promotion to different environment looked like this –
|
parameters: – name: devBuildId displayName: Dev Build Id type: string
trigger: none
pool: vmImage: ubuntu-latest
variables: buildConfiguration: ‘Release’
steps: – task: Docker@2 displayName: Login inputs: containerRegistry: ev-optimizer command: “login”
– script: docker pull ev-optimizer.azurecr.io/bff:${{parameters.devBuildId}} displayName: PullImageFromDevEnvironment
– script: docker tag ev-optimizer.azurecr.io/bff:${{parameters.devBuildId}} ev-optimizer.azurecr.io/bff-test:${{parameters.devBuildId}} displayName: Reassign tag
– task: Docker@2 displayName: PushToTestEnvironment inputs: containerRegistry: ‘ev-optimizer’ command: push repository: bff-test tags: ${{parameters.devBuildId}}
|
There is no code rebuild, it blatantly downloads the developer image and pushes it to a different repository within the same registry. This gives hint on couple of other things – there are multiple repositories in the container registry, the pipeline as such discards the default step to download the latest copy from the source code repository. By default, the code from main branch is downloaded thus, the team might not have branches for different environments.
That leads to the burning question where lines these days are drawn clearly between teams – Do you do still use branches to baseline code for an environment?
Remember we are not saying main branch-based development, here was focusing on baselining code based on branching. Such practices lead to necessity to emphasis advanced governance practices e.g., such code baselined branches should not be open for edit. These thoughts left us to believe the approach to such binary promotions is more lucrative. But, could prove quite challenging when you are not using docker. There are avenues like binary repositories nuget, npm, maven, pypi or numerous others could be used to replicate this based on tag or version number.
If you are left with the question of code stabilisation for a release when will tags help. Provided the source code version control provides that facility it is a handy thing that could be tacked in toaddress just that.
