Having a good strategy to integrate code facilitates communications, and reduce risks and conflicts (for code and people). I use simple terms to explain it and an illustrative comparison with a car factory to understand it even if it’s your first time reading about the topic.
The Mainline Illustration
Imagine you own a car manufacturing company, and your goal is to assemble as many cars as quickly as possible. To achieve this, you need to assemble the parts at maximum speed.
While assembling the parts, you might encounter issues like installing the wrong part, dealing with poor-quality components, waiting for a coworker’s part to be ready, or having workspace overlaps that lead to lost parts. All of these setbacks lead to rework, which translates into delays and impacts your financial goals.
So, you need to consider better strategies to mitigate these problems:
- 🕥 👀 Workflow Coordination: Use a real-time communication system so workers can signal when their parts are ready or if they face delays.
- 🏖️ 🧰 Optimized Workspaces to Avoid Overlaps: Designate specific areas for each worker’s tasks to minimize workspace interference. This reduces the likelihood of misplaced parts and accidental delays caused by crowding.
- ✅ 📝 Quality Control at the Source: Implement quality checks for each part before it reaches assembly. This ensures only high-quality components are used, reducing the need for rework due to faulty parts.
Bringing Those Strategies To The Coding World
Coming to the coding world, the car factory illustrates what happens when we integrate pieces of code into the application.
Let’s expand how the previous integration strategies are are applied:
Workflow Coordination
From a methodology perspective: clarity in the processes, explicit like Kanban or Scrum, and implicit as team consensus, in the other hand the proper usage of tools like Jira; from a team perspective the usage of good communication channels, clarity and respect within the team, consensus and responsibility.
Although these are more people oriented strategies and I’m writing just a bit about it, having good dealings and working relationships it’s the cornerstone of the integration process and I recommend you to improve in your communication skills 😉 because as devs sometimes we forget how valueable it is.
Environments
Are optimized workspaces to avoid overlaps. In general, there are working environments, testing environments, and production environments. We refer to your own machine as the working (or development) environment, a non-production server as the testing environment; and production-ready servers as the production environment.
An environment is the place (hardware and software platform) where the app runs.
Automatic Validations
It’s applying quality control at the source code, before it’s integrated in a main branch or deployed to a non-dev environment. More precisely are a series of validation checks to confirm that everything works as expected or at least to reduce the number of faults in your code at the end of the process.
Pipelines
A pipeline is a temporary environment used to prepare and transfer code to non-production environments.
Here’s a breakdown of the key steps that occur inside a pipeline:
- Build Staged
Generate optimized static files for the production environment. These files are often different from development files, as they are typically minified for better performance. - Static Code Analysis
Check the code’s quality, security, and adherence to conventions by running a linter. - Testing
Run various tests such as unit, integration, and API tests to validate functionality. (I’ve also written an article on testing 🔎). - Containerization
Package the code into a Docker container, making the app platform-independent and easier to deploy. - Deployment
Transfer the static files to the production environment, whether it’s a physical server or a virtual machine.
Automation Strategies
In the development world depending the level of automation in your pipeline people are going to tell you that your are applying Continuous integration (CI), Continuous Delivery (CD), or Continuous Deployment.
Continuous Integration (CI)
The strategy where a pipeline is automated except for regression tests and the deployment.
Continuous Delivery (CD)
The strategy where all the steps in the pipeline are automated except the deployment.
Coming back to the illustration you (the developer) built a car, but business people have a kind of a “red button” to decide when it goes to market.
Continuous Deployment
The strategy where every step in the pipeline is fully automated, which means that every successful build (how is it also know the process of running the pipeline) results in a new deployment.
Which strategy fits best depends on business needs, for example, it’s a business requirement to deliver code updates every day or not; and on the other also in the team expertise, in other words: more automatization = more expertise.
Summary
The code integration process requires strategies to avoid conflicts and failures, some of them are tools as environments and pipelines. Environments are isolated places (physical or virtual) where code lives; pipelines in the other hand are a series of steps that run automatically in an temporal environment before moving it to a non-dev environment.
Depending on the level of automation you can use one of three strategies: CI or Continuous Integration, CD or Continuous Delivery, and Continuous Deployment.
Take in mind that CI/CD workflows heavily depends on the branching strategy you use, visit my second article on the topic: “A Crash Course on Git Branching Strategies” if you want to go deeper.
