Build engineering and DevOps: it seems that never the twain shall meet. Build engineering supplies the build system, with its tools and processes that make software development and deployment easier. DevOps professionals use Agile principles to develop and deploy applications with their teams. Although build engineering and DevOps are distinct but connected activities, organisations are not typically bringing them together.
DevOps has enjoyed growing adoption in the last 10 years or so. Before that, there was a discrete division between coding — done by developers and engineers — and deployment, done by operations (aka “Ops”). However, it became apparent that for companies to optimize benefits and increase productivity, development and operations shouldn’t be so disparate. The result of this alignment is DevOps.
This shift to agile methodologies has produced both positives and negatives. Organisations have traded proprietary code for open source, security for speed and certainty for agility:
- Open source is now widely preferred over proprietary code because of the lower costs, greater innovation and transparency it delivers. Rather than focusing on creating proprietary code, developers can quickly iterate on a solution by assembling open source code and accelerating time-to-market. Plus, the ability to take from what has already been created can free up your dev teams to innovate and build IP for your enterprise efforts
- Getting product to market rapidly has become a fact of life. Speed is now more important than fixing vulnerabilities, which can always be addressed in the next release (hopefully). And retrofitting for security and vulnerabilities after the fact becomes a big blocker for Development and Engineering teams. At the end of the day, the risk of lost profits is greater than the risk of potential unknown threats
- Consequently, agility wins out over certainty. For instance, iterative pushes to production do away with fixed, known roadmaps in favour of implementing whatever this week’s most important feature/functionality is. The trend toward immutability is also important here; it’s generally simpler and quicker to throw away something that’s broken or outdated rather than trying to fix or update it
These trade-offs are easier to handle for organisations with mature DevOps processes. For most, the tension between fixing something and knowing if it will break something upstream hasn’t been eliminated. You may be able to quickly update and patch a single solution, but how will this impact you once you push to your CI stream? Even for mature DevOps organizations, there’s a hidden opportunity cost associated with two factors that are overlooked: open source programming languages and build engineering.
Teams should be focused on the things that matter – creating and delivering the latest release. Retrofitting your open source language of choice with new versions, dependencies, security patches and so on adds overhead to your DevOps teams.
Build engineering suffers each time the underlying open source language is retrofitted. You need to rebuild all your developer environments, CI/CD systems and production environments. All of this build engineering work is manual, slows down time-to-market and eats up valuable engineering resources. Plus, you’re not certain your rebuild and update will provide performance improvements that warrant the update.
Since DevOps relies on automation, why not automate the retrofitting and building of your open source languages and seamlessly connect to the rest of your DevOps cycle? You could ensure build reproducibility, dependency management and compliance with your corporate security and license criteria. For example:
- System update: What if it were possible to update all of your impacted systems across dev, test and even production environments with the latest build using a single command?
- Build validation: How would workflow improve if every continuous build could be vetted against your smoke test, inclusive of compliance with your security and license criteria, so you knew whether it was ready to deploy?
- Continuous builds : Imagine that a new build was kicked off every time a new version of a library or patch for a vulnerability was found – and you were notified when it was done. Then you could keep up with your continuous deployments
- Packaging: How might your workflow change if each continuous build could be packaged in multiple ways — any form factor for any operating system?
- Build impact: Imagine being able to understand the performance improvements (if any) that could be gained by taking the latest build?
DevOps methodology brings significant benefits to software development but it also brings some nasty surprises. Updates may work in one area but prove disastrous in another. Automation can help smooth out the bumps in the DevOps road. Automating the build pipeline for open source languages puts a stop to the chain of unintended consequences. This connects build engineering and DevOps for better outcomes.
Interested in hearing industry leaders discuss subjects like this? Attend the co-located IoT Tech Expo, Blockchain Expo, AI & Big Data Expo, and Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London, and Amsterdam.
