Recently, I've been asked by a group of people to provide arguments that should convince developers and managers to use a CI/CD infrastructure. If you're a developer and you haven't been frozen in an icy lake somewhere in Greenland for the past 8-10 years, you don't need to be convinced. Please, move on. You'll only read what you're used to do daily. And to thank you for stopping by, here's a nice photo of a dog:
So, if you're still here, it means you're in doubt of how CI/CD will play a role in our software development utility belt. Although we all know that automated tests and even a simple CI/CD infrastructure are the foundation of modern software development practices, I wasn't able to answer their questions right on spot. I mean, it's obvious that what we do has benefits, but we still don't know how to quantify them. Often, we see folks banging their heads against the wall trying to figure out why, for Christ's sake, must I test if there's a QA person dedicated for that? And they are right, why?
Because...
Obvious benefits:
- You code is... compiling!
- Errors introduced can be detected and fixed earlier
Hidden benefits:
- Developers tend to be more cautious whenever there's an Orwellian kind of system watching their steps--hence, less failing commits
- When developers are more cautious, they tend to commit more often and in smaller units
- When you commit in smaller units, you're able to revert modifications more easily
Obvious benefits:
- If you have a tool that can run automated tests for you, there's a tendency to... automate tests
- Compilation only doesn't ensure your product is working properly. Well, tests does
- When detected earlier, errors can be fixed earlier
- Automated tests helps you to find out how broken features propagate throughout your codebase
Hidden benefits:
- If you have a successful build, rest assured your codebase is feature safe
- Tests which fail often tend to be refactored. Refactoring tends to have a better design (more modular and with lesser complexity)
- Developer confidence levels tend to grow during development: "If it didn't fail, it's ok"
Obvious benefits:
- We can release at any time
- We can test our release process right after changes are introduced
Hidden benefits:
- Customers get to test your product earlier (think of a beta release), and there's no test like real software usage
- Developers can control the product lifecycle--from inception, design, and development to production
- You can push a fix to production just by committing
Obvious benefits:
- It's compiling, tests are running, and there's a release ready to be used. That's very solid
- They have more time to focus on exploratory tests. That's when they simulate a real customer using the product
Hidden benefits:
- It's not only about features. There's user experience. QA people will have more time to check on that as well
- When a bug is reported and fixed, CI/CD enables a QA to work with the latest snapshot. No more waiting for the ops folks to do something.
If you start planning on having smaller development time-frames, such as a sprint in Scrum, you can focus on having enough of a feature per sprint. You don't need to build it all, it's worth building it piece by piece in order to avoid big bang kind of integration.
You start by taking another approach on software development. I mean, does the user really need that CRUD for the user management API? Won't it be enough if I insert data manually for a couple of weeks and ship the system right away? Food for thought.
Hope it helped.