Take your pick: Build-driven Delivery or Image-driven Delivery?
In the recent past, software has seen a revolution of sorts. The emergence of Docker and the containerization paradigm has questioned the basis of some of the software delivery principles. The result? People are opting for things unheard of some two years back. What’s more, they are now using them successfully to deliver software faster and cheaper.
But the question here, is – Build-driven delivery or Image-driven delivery?
Last few decades saw that software was packaged and developed by a build system and tagged with a number; testers aligned their testing to the tag as the entity being tested and promoted them until it gained production. The build ‘number’ was one of the most significant tags.
With the advent of Docker, several teams moved to image-driven methodology, where the ‘image’ states the version of software. Every change in an application program and deployment program will together create a new image; this is tagged and utilized as the version of the software to be introduced for downstream use and finally into production.
But, which is the better option?
All about ‘Build-driven’ Delivery
Irrespective of the target hardware and other deployment options, ‘builds’ helps software to be tagged. It bundles all dependencies to ensure the software works. Here, it gives the development team a satisfactory lever to jump on to the next set of work, or sprint.
Builds are much smaller in size, as the build bundles only important software needed by the application. So, aligning with every change will not be a costly storage proposition.
One of the important tools like maven is to build and link dynamically, the versioning of artifacts and bundling them at run time and help collect all dependencies from the Cloud. This leads to an easy thin build and additionally minimizes the redundant data to be kept in each build.
Over the years, build repositories have fully developed to deliver a quick way to version and locate dependencies, so deployment tools can find new versions and automatically enhance environments as required.
Understanding ‘Image-driven’ Delivery
Images take the idea of build to the next level, ensuring the variability in target hardware and deployment options are eliminated completely. It bundles the application as given in the build or built as part of the image creation and pushes the image as a build.
Starting to compare and contrast themselves into a build repository are Docker registries, by providing similar options for end users.
Providing a much better benefit of standardizing all your environments, is the images-driven option. Images are much bigger than builds, given that it has to carry now the system software and the base application software within the image. This option was not known earlier, but with container images being reduced to megabytes. Layering sizes can be slashed much further as you zero in on dependencies.
The choice depends on where your application is in its life cycle. And, the research teams should ask for:
- Are we making a big shift to choose for an incremental benefit?
- Is there an issue of environmental differences?
- Can I club these choices to get a hybrid solution going?
However, the final verdict is – An Image-driven solution is an ideal route to bring DevOps culture to a team. If the magic of image clicks, then it is a win-win situation for your team!
