This document is for Build Engineers, DevOps Developers, and the people who hire them: Software Development Manager, VP Software Development, Director of Software Development. The goal of this document is to show how to improve a software environment using modern tools, such as those used in a DevOps environment.
First is a description of Build Engineering, next, how Build Engineering can be modernized with today’s tools and processes, then a discussion of how DevOps relates to a modern Build Engineering system.
The conclusion is that much of DevOps tools and processes are required by modern Build Engineering and can be used to improve any software development environment.
A Build Engineer makes things happen for a software development team, so they can build and run the latest software and test it, and use their many tools.
Software development teams use several types of systems to manage their software and processes. The most common are:
- Software development planning systems, for waterfall or agile
- Version control
- Issue management
- Software build, usually with Continuous Integration (CI)
- Integrated Development Environments (IDEs) and other editing and debugging tools
- Automated testing
- Automated packaging
The role of Build Engineer may be responsible for all of these systems, but the most important part of the role is creating and maintaining the software build system and automated test system. This requires custom scripting.
Modern Build Engineering
These are some of the most important changes. These technologies are also required by DevOps. Your workplace may require different changes, based on the software you are building:
- Automated builds used to mean the “nightly build”. In modern environments, any change on main branches will trigger a build.
- Modern CI tools such as Jenkins and Cruise Control reduce the custom software development required to build, test, and package products automatically.
- Version control needs to follow more of the characteristics of Software Configuration Management: use a branching strategy that supports your workflow, and follow other best practices for your version control system.
- IT may take over some of the tools when there are several dev teams, or when non-dev teams are using the same tools.
- An Agile software development process, such as Scrum, can help your team develop software faster, if implemented well. However, many Agile ideas have become “the new way you do things”. As a result, you are likely following many Agile techniques, even if you are not officially using Agile.
- Agile processes mean repeated testing, builds and packaging at short intervals. Test automation is necessary. Difficult test automation becomes more urgent.
- Your team needs sufficient process docs and tools docs for others to take over during vacations.
- The team must build products and packages in a reproducible manner. To be reproducible, at least the following is required:
- A stable, controlled environment and controlled processes.
- This includes change control on the source code, the build systems, and the deployment systems.
- You must be able to rebuild old released versions of the product, generally with the same tools, in the same versions, as you used at the time.
- Build and test processes must be captured in a script that anyone can use, not just the developer who figured out the process.
Build Engineering and DevOps
DevOps is the next step beyond modern Build Engineering. If you have implemented a modern build Engineering environment, DevOps requires the following new work from your development team:
- Insist on really good automated testing.
- Before you fix a bug, write an automated test for that problem, so it can’t come back.
- Consider breaking your product into micro-services, so you can deploy changes to each micro-service independently of changes to the rest of the system.
- This may not seem to make sense for systems used by your customers on their own premises. However, consider the relative cost to your customer of retesting a small service versus retesting your whole product.
- This is a big change. Research it, move into it a bit at at time, discuss the design changes with the whole team. Make sure the micro-services are actually independent.
- For projects deployed as services, work closely with “Ops”, the part of the IT department that deals with operating your corporations always-on systems. Get the support of high level management for this collaboration.
You also need to do the following for customer-facing online services:
- Deploy your application to Amazon or another cloud service as a scalable service.
- Automate that deployment so it is a one button task. There are generic tools for this, that make it simple to define what you want and let the tool deliver the right things at the right time. Don’t write one from scratch!
- Automate rollback so that one button rolls back to the last deployed version. Some of the deployment tools make this easy, once you have implemented the deployment side.
- Add Continuous Deployment, by providing your automated system with rules for “good enough to deploy” and “broken enough to roll back”, and letting that software handle your releases.
- Work with Ops, or create a separate DevOps team, to make these steps happen.
In my opinion, every software development team, using DevOps or not, should apply modern tools and processes.
For instance, with internal custom enterprise software deployed to your own servers, you can use DevOps tools to automate that. For a company with multiple locations around the world, you can also deploy your internal service on cloud services, or in your data centers at each site.
DevOps is the next evolution after Build Engineering. Your team can start using DevOps by using modern Build Engineering practices, and add the rest when you need it for cloud-based services.