Introduction to CI/CD⌗

What is CI/CD? I’ve seen this term many times over and over. On resume’s, LinkdIn profiles and many more locations. But what is it really.

CI/CD can be split up into 3 different parts.

  1. Continuous Integration
  2. Continuous Delivery
  3. Continuous Deployment

Lets dive into each one to see what they are.

Continuous Integration⌗

Continuous Integration is basically testing everything continuously. Checking if all integrations are correct and in spec. And this means that all developers own working copies of the product’s code are merged daily. The higher the frequency the better in my humble opinion.

Once merged, tests are automatically triggered. Workflows or pipelines with different kinds of tests are running to do a static analysis of your code, executing unit-tests and executing possibly even functional tests. Actually confirming your code is operating as intended.

Continuous Delivery⌗

Continuous Delivery is when the Continuous Integration testing has completed successfully. Delivering the new version of the product. Over and over again.

Preferably the product is versioned with semver 2.0.

Continuous Deployment⌗

Continuous Deployment is when the Integration is successful and the Delivery is successful. After which automatically the Continuous Deployment process is engaged. Deploying the new version of the product.

Usually the CI, CD and CD are combined in a singular pipeline. Possibly even deploying it to dev, test, acceptance and production. But this depends all on the policy of the company.

Principles⌗

Be agile⌗

The Team and hopefully the organisation are operating on a Agile Framework. And in my opinion there are 1001 different implementations of such. But they all tell you basically the same thing. Waterfall is bad.

An agile Team means the Team it self is autonomous. Self steering and shaping. Therefor also managing stakeholders is done by the Team, usually by the Product owner. Ultimately achieving proper handover of product deliveries.

If not, it will never be continuous delivery… But an eventually deployment…

Tests are important⌗

Testing is important. Without it you actually can not know for certain that the code actually works. Test Driven Development (TDD) is a good thing to do. Write your tests, then your code (I’m fine with the other way around too.). But importantly write your tests!

Your tests proof that your code works. Based on that proof the workflow or pipeline can give a pass or fail accordingly. And if all tests are good, the integration is done. And the package can be delivered.

But be sane about what you test. You should ideally test only developer made logic. Not your vendor’s code.

T-Shaping your Team(s)⌗

The agile team is composed of members with different competences and specialties. But everyone should know the basic understanding of the one and other. This way the bus factor is kept as low as possible.

This by no means implies that every team member needs to know everything. This would be an impossible task.

But T-Shaping is not limited to your team only. But to the whole organisation. Because you own the code, you also should own the pipeline (as code obviously). If you do not own the pipeline, how are you going to make sure it’s compatible with each other? So we need to educate ourselves, team members and the organisation to adopt the agile way of working. It’s a team effort.

Bigger teams are better?⌗

No. This is far from the truth.

Ideally your team should have about 8 up to a maximum of 10 people, preferably no less then 4. This way you ensure less disruptions with handovers to team members. This also allows teams to focus more. Even when we are building a large product. You’ll have multiple smaller teams with each their own focus.

Everything as code⌗

Everything as code that’s the purpose. Your program, pipeline and tests. Heck if it were up to me even the documentation. Write it all as code. This way everything is in the same place. Easy to read, search and review.

Efficient pipelines⌗

If you’re going to look for the CI/CD Principles on a search engine you’ll find that people want fast pipelines. About as fast as a coffee break. I slightly disagree here. Pipelines need to take as much time as they need. In order to deliver quality over quantity. It does not mean I’m saying a slow pipeline is good. But aim for efficiency without loss of quality.

It is all about the fast feedback loops.

Broken pipelines are the worst⌗

Broken pipelines are the worst therefor they must be fixed with the utmost priority. Because your team mates are stuck too because of it.

Run the pipeline before it self⌗

You should be able to do what the pipeline does, locally. This means that you should be able to execute the tests and build locally in a clean environment. The pipeline is always right even if it works locally. Hence you need to be able to test locally in a clean environment. And remember, the pipeline is always right.

Commit to master?⌗

Ideally yes, but with multiple developers it’s easier to just have short lived feature branches. I personally prefer short lived feature branches over straight into master when working in a team. But please do not do a full fledged git flow.. This is terrible.

To scrum or not to scrum⌗

Scrum is a nice implementation of a agile way of working. Where one does the Spotify model the other does another thing. But also scrum has its limitations. For example operational support does not fit into scrum. But it does fit in kanban, also another way of working in the agile way. Best advice I can give here is that you need to look and reflect on what is the best for the team. Retro’s are a good placeholder for this.