Why practice Continuous Integration? What is the Business goal behind improving engineering practices? What if we were to make this into a user story? What would it look like?
“As a business, I want the ability to introduce features and functionality to my customers with very little risk, so that more people will buy and use our products.”
How would we accomplish this goal? You might start with a shift to a leaner process. One that would shorten the feedback loop between customers and the developers, on features and products. This would help ensure you are building what they actually want. You might design your teams around products instead of subdividing the company by “IT” and “Business” and then further subdividing technical teams around technological silos and businesses around domain silos. Those would be great steps to take.
So how then do we deliver the product? We probably create product teams comprised of business people and technical people. These team members collectively have all the knowledge needed to create the product. So how do we get it, and subsequent changes, to market in a world that wants everything right now? Without exposing the company to the huge risks associated with big-bang software releases?
The silver bullet seems to be “CI/CD”. It is on everybody’s lips. But do they understand it? Most people think CI/CD is a hardware/software pipeline where things get checked into a version control system and are "automagically" deployed to production. But is it just software and hardware with some automation mixed in? When I ask people if they need help with engineering practices such as continuous integration, they often respond with:
“We are already doing it. We have Jenkins. We use git.”
“Hmmmm. So ‘having Jenkins’ and a repo means you are practicing Continuous Integration?”, I ask.
“Well… we check into git and then Jenkins runs a build.”
“Ah! Cool! So all your code is integrated together and then you execute a test of all your functionality automatically through an automated test suite?”
“Well, no. Not all our functionality. Actually, we don’t really have a lot of automated tests.”
“So you are just verifying the compile??”
“Um… yeah.”
The bottom line is that when we start probing we find that the practice of Continuous Integration is not being followed. So… They have the hardware. They have the software to kick off a build. But they are lacking in test automation or at least lacking in “good tests”.
Side note: assertNotNull(Object) does not qualify as a good test.
“Continuous integration is a practice–it is about what people do, not about what tools they use. As a project starts to scale, it is easy to be deceived into thinking that the team is practicing continuous integration just because all of the tools are set up and running. If developers do not have the discipline to integrate their changes on a regular basis or to maintain the integration environment in a good working order they are not practicing continuous integration.” - https://less.works/less/technical-excellence/continuous-integration.html
Giving CI to dev teams without teaching them how to practice it, is like giving a hammer to a six-year-old. Just because the six-year-old is able to lift the hammer, doesn’t mean he should. To use a hammer properly one must know its purpose, the right applications for its use, and develop the proper motor skills and coordination to use it effectively. Without that knowledge in place, things just get smashed. CI is no different. It is a tool used by developers. Developers must know how to employ it as it is a practice. They must change the way they work and change their habits. This is hard enough to do for a small team without coaching. Attempting to implement it at scale without technical coaching is pretty near impossible.
The six-year-old may be able to pick up the hammer, but that doesn’t make him or her a carpenter. It just makes them dangerous.
We can talk about Continous Deployment on another day. Teams should concentrate on learning Continuous Integration first.
No comments:
Post a Comment