First of all, you have to know that developing code is like taking a 10,000-word dictation and getting a 0 on the first mistake.

It's scary isn't it?

Now you can tell that many people have to share their 10,000 word dictations before they are corrected.

Well, we can tell you that it's not easy.

If no quality testing is done after the code branches are pooled, then it will be your client who will see the project break.

This can be a real time bomb for your projects.

TIC...TAC...

Even if each piece of code works independently on its own branch, there is no guarantee that it will work properly after being shared with other developers' code.

Would you be willing to take that risk?

This is one of the big problems facing developers: "Integration Hell".

When it comes to production, it's the merging of these different pieces of code that can cause problems, and it's often the entire technical team that is mobilized to find the needle in the haystack.

To follow up on this little introduction, you are probably asking yourself the question :

"But how do you ensure the stability of a project from start to finish?"

Well, that's where CI/CD comes into its own!

You should know that CI/CD allows you to reduce the hours spent on tool chain maintenance by at least 10%, which is not negligible!

Source : https://docs.gitlab.com/ee/ci/introduction/

In short, CI consists of automating the process of integrating code modifications into a common project, i.e. automating the verification of compatibility between the different branches of the code.

How is this automated?

Like a game, you have to "define the rules".

The CI/CD guideline is dictated by a pipeline, which is a set of steps (build, test, deploy, ...) describing the different tasks to be performed to ensure the quality of the code and to authorize its merging with the trunk (the shared version) which can then be automatically implemented and manually tested in a staging environment: this automated implementation is called "continuous deployment", the famous "CD" of CI/CD.

Is it more convenient to write your text, then activate a proofreader to catch your mistakes and correct everything at the end; or to activate an automatic proofreader that will allow you to correct your dictation as you go along?

You will hear that we prefer to correct errors as soon as they are identified rather than correct everything at the end.

In development it is not Word that corrects us but different tools that allow to write and run a CI/CD pipeline, such as GitLab-CI, Jenkins, or GitHub Actions, each offering their own advantages.

We integrate lines of code as we develop, so we don't have to integrate everything at once and identify problems when the project is delivered.

This saves time and increases responsiveness.

Agile, isn't it?

And yet you should know that this is not enough!

TIC...TAC...TIC

After the manual tests carried out on the staging environment by the QA (quality assurance) team, if they have not found any issues, it is time to deploy this version in production (main environment, public); this operation is usually manual, in order to give the managers the opportunity to roll back to the previous version in case of problems. If you're bungee jumping, there's nothing to stop you from thinking about a safety net.

Test + Safety net = Security

Whether it's the writing of the pipeline tests, the shared version, or the main version; when developing a project it is essential to define the supports well from the start!

Otherwise, it's a mess:

Let's take two developers working on an aircraft altitude analysis system.

One is in charge of programming the altitude calculation and the other is in charge of setting the autopilot parameters.

Both do their job and everything works at first sight.

Everything works until we deliver the project and the customer brings up a problem with the altitude calculation.

With CI/CD, the units of measurement would first have been defined in a pipeline and the code branches could not have been integrated with each other because they would have been considered incompatible.

When searching, they would have realized that one developed his code with meters as the unit of measurement and the second with feet.

Problems are detected as early as possible with CI/CD, whereas without it, the branches would have been integrated and the problem found later, causing a delay in the project and forcing your developers to spend time looking for them.

If it were just this type of complication, it would be easy; but your development teams have different issues to deal with at the same time, like versioning for example.

They work on a source code and keep the previous versions after modification.

In a versioning problem your developer is not developing on the same branch as the others and may find himself solving issues that have already been solved.

In summary, the development process using CI/CD is divided into 3 different checkpoints to ensure the stability of the code: automated tests independently of a deployment ("from scratch"), automated tests performed during a deployment on the staging ("live"), and manual tests performed by the QA team on the staging before going into production

In the CI/CD approach, the stability of the code can be monitored throughout the application's life cycle and the working materials are clearly defined to avoid any confusion.

It is important to be able to continuously check the stability of the code, especially when you modify it, remove or add functionalities after having processed feedback from your clients.

This is because as a project grows, it contains more and more code, which leaves greater opportunities for bugs to creep in, either in the form of a change that causes unexpected behavior in a (seemingly) unrelated part of the system, or in the form of a complex test case that wasn't anticipated by all the developers.

While it is possible for developers and the QA team to recheck the entire code base and functionality of the project with each change, and in addition to being a huge waste of time, this becomes extremely difficult if not impossible as the project grows: the amount of testing and patching required becomes exponential to the size of the code base and the number of features.

CI/CD, in addition to providing guarantees on the robustness of the product (and serenity for the developers...), makes it possible to avoid this exponential curve, regardless of the size of the project.

TIC ...TAC... TIC..TAC.…

As you can see there is no BOOM with CI/CD. 😁

This is how we methodically handle the development of our applications at the Digital Factory Paris, we reduce the risk of delay in our projects as much as possible thanks to an agile method and adapted to our projects.

Subscribe to our newsletter

The CI/CD approach: THE good practice that will save you a 0 in your dictation

Contact us