For federal agencies, speed is the elusive golden ring. You want to move quickly and build great digital products, but you have many regulatory and compliance issues to grapple with, and these inevitably slow you down.
How do you achieve the speed necessary to meet user needs? How can your software organization become nimble enough to make fast changes, without introducing new bugs or complications as a result of that speed?
It is common practice for software organizations build up large parts of the codebase over a long period of time, and then release them into the wild all at once. This often leads to unexpected outages or bugs affecting large parts of the user base and requiring massive emergency actions to clean up (think Healthcare.gov circa 2013). While introducing bugs is an inevitable part of creating and improving software, there is a way to massively improve speed and agility while mitigating the fallout your organization creates.
When you want to paint a room in your home, how do you do it? Would you just think for a long time, choose a color, buy 2 gallons and then paint the entire room all at once? Probably not. Too much risk, and it’d be a huge pain to have to repaint the entire thing the following weekend if you chose the wrong color.
A better idea would be to get a paint chip and tape it to the wall, so you could “test” it. See if it clashed with your sofa. Observe how the color looked at different times of day. Show it to your mother-in-law to see if she hated it. These tests would help you determine if this color was a success. And in the event it didn’t pass muster and you needed to make an adjustment, it’d be easy — no hassle at all.
Making changes to a codebase is similar: the smallest change you can make that brings incremental value to your users is the one you should be making. You should have built-in tests for those small changes in code to make sure that they won’t get you into trouble (with your mother-in-law, or 10,000 constituents) later down the road. And in case you do run into an issue (which you probably will), small changes are easier to fix.
In the world of software, this is known as the process of continuous integration and continuous delivery. Developers practicing CI/CD write code in small chunks, write tests for each piece of code, and then, once the tests pass, the code is merged into the master codebase and disseminated to end-users immediately. Feedback is gathered quickly. If there are issues, they can be isolated and fixed rapidly, without taking down the whole ship. This method allows greater speed, while at the same time reducing risk.
By employing continuous delivery, you amortize the risk of releasing big changes across many smaller changes. It also keeps your team focused on:
- Building code that can handle breaking,
- Processes that can detect problems quickly, and
- Shipping value to users as soon as it’s ready.
CircleCI is a continuous integration and delivery platform designed to help organizations build software faster, with higher quality. CircleCI automates the build, test and deploy process, enabling your team to release software with confidence and get feedback rapidly. CircleCI allows a combination of tight feedback loops and good test practices to keep your risk profile lower than using traditional software development methodologies.
No matter how much lip service we may give to “embracing risk”, our objective as software developers is still to minimize it. Making your releases more incremental will help you speed up, reduce risk, and ultimately deliver value more quickly.
Gillian BenAry empowers engineering organizations do their best work via CircleCI. CircleCI is a continuous integration and delivery platform that helps software teams rapidly release code with confidence by automating the build, test, and deploy process.