Why do you really need CI/CD? Short answer: Because CI/CD could help your team deliver new product features 106 times faster!

Having no CI/CD is like driving blindfolded on Lombard Street in San Francisco.

Lombard Street in San Francisco, image by AFAR

Software is complex

"Complexity is the state of having many parts and being difficult to understand or find an answer to." — Cambridge Dictionary

The problem is, our brains are limited in how we process information and the reality around us:

• Our working memory is limited
• We have many cognitive biases
• Our brains construct reality

Why is that important? Because software is inherently complex. We don't understand it. We have no idea how it works. We have no idea what will happen if we change anything.

Think about this: If you decide to change your curtains, you get instant feedback. It's a simple task. You can see how your whole room looks with the new curtains and you would know instantly if something doesn't work.

In the world of software, the situation is completely different. If you decide to change a function or a class, you have no idea if you'll break something. You can't see the system. You don't understand the system. You have no idea how the system actually works. It's just too big and complex to comprehend. Your reality is the parable "blind men and the elephant".

"So what?" You might ask. Well, CI/CD is one of the ways to get a hold on complexity and build knowledge of how the system reacts when you make changes. It's worth noting that CI/CD is also about reducing waste in your workflow but that's a second objective. Efficiency only becomes important when you're at the right scale. But CI/CD is relevant for any scale. CI/CD can improve the quality of your product significantly even if your team is small.

Systems Thinking

The importance of Systems Thinking in our daily lives can be illustrated with the the parable "blind men and the elephant". A lot of things we experience are too complex to understand, so we only know a tiny aspect of them.

Systems Thinking has several key lessons for us:

• Everything is connected; hence what happens in one part of the system affects another
• Cause and effect is neither a linear nor a one-directional process
• Context matters; a lot!

So, what exactly is a system and how is it relevant to CI/CD?

"A system is a set of things — people, cells, molecules, or whatever — interconnected in such a way that they produce their own pattern of behavior over time." — Donella Meadows, Thinking in Systems

This is an interesting quote. It tells us something really important — the system causes its own behaviour. So, if we want to "fix" the system — get more of something or less of something — we need to understand how the system works. Otherwise, we're just playing Whac-a-Mole — we "fix" something but there is no lasting effect. In Software Development, we might want to get less bugs, less rework, faster deployments, better product features, shorter release cycles, happier teams, etc.

CI/CD is a perspective on how the system works and what can be done to change its behaviour. In our case, the system is the software development process with all its inputs (people, resources, ideas, users, etc.), and the product or software is one of the results of the behaviour of the system.

So, how do we change the system? One of the ways to get the desired outcomes in a system is to understand and use feedback loops. That's exactly what the core idea is behind many CI/CD practices.

Feedback loops

"Feedback loops are typically used to accomplish regulation and control. A feedback loop is like an input, but its origin is from within the system itself, not from outside the system. In many systems, the output reenters the system as another input. This is exactly what happens with a microphone and speakers when the sound from the speakers feed back into the microphone, often causing a loud squeal." — Courtney Brown, Graph Algebra

Feedback loops are a deceptively simple concept. In practice, they can get quite complex. The key thing is knowing what feedback loops to amplify and how to make them work for your team.

Feedback loops are essential to ensuring quality, yet many organisations develop software "in the dark", without having the right feedback loops available. One of the benefits of CI/CD is that it establishes feedback loops in the development process helping organisations improve the quality of their products.

Feedback loops in Software Development, image by Danny Smith

Finally, in simple terms, in order to deliver quality product to the end-users, the teams must ensure that feedback loops focus on confirming two things:

1. You're building the thing right (unit tests, regression tests, etc.)
2. You're building the right thing (team review, user feeback, etc.)

Workflow stages

If you were to look at your development process, it would look something like this:

• Plan
• Design
• Code
• Build
• Test
• Release
• Deploy (manually if it's Continuous Delivery or automatically if it's Continuous Deployment)
• Operate

Continuous Integration includes the following stages:

• Code
• Build
• Test
• Release

Continuous Delivery includes the following stages:

• Deploy (manually)

Continuous Integration

At its core, Continuous Integration is a really simple idea — get the different types of feedback (automated, user, stackeholder, etc.) on your changes as early as possible so you can fix issues early (saving time as the problem context is still in your head), avoid problems downstream and ultimately have feature sets that are ready to be deployed to Production. Achieving this objective is no simple task though. Here is a list of practices you need to successfully adopt in order to ensure early (and fast) feedback, as well as making sure your team acts on it:

• Make changes in small batches and integrate them frequently into the mainline of the project
• Add your changes to Version Control to enable parallel streams of work
• Write fast tests (slow tests are a bottleneck)
• Continuously test all changes to identify bugs quickly (this includes always running unit and functional tests)
• Get someone from your team to review your work
• Automate as many build tasks as possible
• Get notified of any broken builds as soon as possible
• Fix broken builds as soon as possible

So, in order to get fast feedback for every change to your repository you need to have the above practices implemented.

Continuous Delivery (CD)

"Continuous Delivery is the ability to get changes of all types — including new features, configuration changes, bug fixes and experiments — into production, or into the hands of users, safely and quickly in a sustainable way." — Jez Humble, continuousdelivery.com

Continuous Delivery aims to ensure that releases are always in a deployable state. Deployable state means that the feature sets that are available are tested, reviewed, and are ready to be deployed to Production.

Additionally, when you have Continuous Delivery, there is no more deployment pain. Deploying releases to Production is not a difficult thing to do.

For a reference: When you are doing Continuous Delivery, you're deploying releases to Production manually. This is different to Continuous Deployment when releases are deployed to Production automatically — there is no human intervention.

Metrics

How do you measure the state of CI/CD at your company? Here are the key 3 metrics:

• Release cycle time: Cycle time starts when the actual work begins on a user story (or task) and ends when the user story is finished. The user story is usually finished when it's deployed to Production. How long does it take your team to take a user story from concept to Production?
• Deployment frequency: The higher the level of automation is in your workflow, the more frequently you can deploy releases. How many releases do you deploy per week?
• Change fail rate: If broken releases get into your Production environment more often than they should, it's an indicator of problems with your CI/CD workflow. How many bugs do you find in your Production releases?

Salesforce

"Well, this doesn't apply to us as Salesforce is mostly point-and-click configuration. There is little code to write." — you are probably thinking.

While it's true that Salesforce is mostly point-and-click configuration, it's still a complex system that changes often. For example, creating a simple validation rule might send ripples through your Salesforce instance breaking integrations, preventing users from creating records and causing a spike in Support cases raised internally. That's just a very simple example of what could go wrong.

The more custom your Salesforce instance is, the less understanding your Salesforce Administrators and Developers have about how that instance actually works. What that means in practice is that when there is a bug it could be super hard to identify the root cause, so it could take many hours to debug the issue and come up with a fix.

Another side-effect of having a complex system but no CI/CD is the hesitance and the lack of confidence among the members of your Salesforce team. So, your Salesforce team is hesitant to deploy new features and instead have features piling up in a sandbox, waiting for a Big Bang deployment.

The bigger the scope of changes in any particular deployment, the more risk and uncertainty the deployment has. That's exactly why the Big Bang deployments are super expensive — they are extraordinary events in your company's life that need many people to work together on in order to get them completed. Here is a typical list of steps your company would need to complete if you're doing the Big Bang deployment:

• Schedule the "maintenance window"
• Form your release committee
• Prepare the rollout, rollback and communications plan
• Schedule a go-no-go meeting with the release committee
• Press the release button and go through the deployment pain
• Send the "soft launch" email (aka "things didn't go according to plan but we are working on the fixes")

Those Big Bang deployments always remind me of the Oscars! Because they're so special and everyone needs to know about them. But deployments should not be like the Oscars! Deployments should happen often (not once a year), be no big deal and cause no issues.

DiCaprio's never-ending quest for Oscars is finally over but our quest for better CI/CD will never be over! (Source: MTV)

How can Bluuberry help?

Bluuberry delivers both Continuous Integration and Continuous Delivery to your organisation. Uniquely though, Bluuberry is built for Salesforce and it automates most of the Salesforce CI/CD tasks hiding the CI/CD complexity from your team.