Why practice Continuous Integration? What is the Goal? 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 without disruption.”
How would we accomplish this goal? You might start with a shift to agile. This would shorten the feedback loop between customers and the developers of features and products, thus ensuring you are giving them 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 have product teams of comprised of business people and technical people that have all the knowledge needed to create the product. But 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 currently associated with big bang software releases?
The silver bullet seems to be “CI/CD”. After all, it is on everybody’s lips. And they may be on to something. But do they understand it? Most people think CI/CD is a hardware/software pipeline where things get checked in to a repo and automagically "delivered/compiled" by Jenkins. But is it just software and hardware with some automation mixed in? When I ask people if they need help with engineering practices or with 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?”
“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 a test automation 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.”
And there are other varied responses to this question. But the bottom line is that when we start probing we find that the practice of CI is not being followed. (And CD? They don’t really distinguish between the two.) 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”.
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 scrum team without the proper coaching. Attempting to implement it at scale without the proper 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 CD on another day. I think we should concentrate on nailing CI first.
No comments:
Post a Comment