The Build/Deploy Tax


Projects often forget about the build/deploy tax.   These days its thrown under the DevOps banner, and often being left to the appointed DevOps individual to wade though and resolve whilst the rest of the team stream ahead with adding new features to the product.

Unfortunately, similar to deciding a testing strategy at the start of a project, and evolving the strategy along the road, build/deployment should be consider in the same context.

Specifically, the build/deploy tax is the duration of time (waste) that it costs the team, from “git commit” to deployment of application to an environment e.g. development, UAT, Integration, Production.  This tax is often measured in terms of time wasted “waiting for the build/deployment process to complete”.

There are many factors that influence the build/deploy tax, a few of which are listed below:

  • Jenkins (CD server) hardware
  • Proximity of build assets e.g. locations of source code repository, nexus, npm, docker registry,  test/prod environments
  • Structure of source code repository and asset deployment

Often the above issues are hotly debated by both the team, IT support and finance.  Examples being:

  • Source code be in a single repository or multiple (e.g by micro service)
  • Monolithic deployment, or deployment based on services that have changed
  • Leverage cloud services e.g. DockerHub or run everything within a separate environment e.g. AWS

Unfortunately, there often isn’t a simple solution to many of these problems.  AWS maybe right to running all your build/deployment infrastructure, but the last mile to Prod may still be “painful” due to Prod not being in AWS.  Maybe this is an acceptable cost?

Advertisements

~ by mdavey on October 27, 2016.

One Response to “The Build/Deploy Tax”

  1. Yes, build/deployment should be included in the project from the start and started at the same time as software development so the infra is ready and working then it is time.

    Concerning prod vs test environments differing I have found using app-container tech like Docker/Rkt in conjuction with Kubernetes being very useful. With this infra it does not matter anymore if test or prod is AWS, VCenter, Cloud, physical server, or something else.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: