CI/CD or quality code pipeline

While releasing project updates we often find a bug or an error on the production service that can occur for different reasons but it did not occur on the test servers before. As a result, the client faces with different inconveniences up to the whole project failure. It does not seem important if we talk about one-page landing pages when a potential client can not find how to contact the company, but it turns into a serious problem if this is about an online shop that becomes unavailable and the client literally losses his money. Especially in FinTech sector where every single second of a non-working service results in colossal financial losses.

Can we avoid the fear and hate on both customer’s and an end user’s sides? Or can we save a significant part of time from the total amount of development hours? Our answer is YES, and CI/CD methodology will help us.

Continuous Integration (CI) and Continuous Delivery (CD) embody a culture, a set of operating principles and practices that let the developers implement software changes more frequently and reliably.

Once Henry Ford shifted car manufacture from hand-assembled into an assembly line, thus he optimized the production of his time. CI/CD principle (Continuous Integration & Continuous Deployment) looks quite similar to a pipeline one: the method performs an integration function, including different types of automatic tests at each stage and then it delivers and deploys the code into a final product for the end user.

Our agency CHILLICODE has recently implemented CI/CD in the majority of our projects, that gave us a possibility to establish an update release process just in one click, to reduce the risk of bugs by autotests and code quality analysis before every release, and also to eliminate the differences between hosting environments of the developer and the server by packing the app into the so-called «containers».

We offer to set CI/CD system to our clients who request regular updates for their projects. Thus in the beginning we spend some time to set up the environment for Continuous Integration and we will reduce the risks and will be able to offer the client to spend this time on some more challenging tasks.

What release stages can be automated?

• Testing and quality control

Definitely, these are the first points to mention. We can not replace the testers completely, but the main part of the repetitive tests can be automated through unit and regression testing. We offer automation squared. CI/CD simulates the runtime of the target server and runs tests automatically to confirm that the software is working fine and to COMPLETELY EXCLUDE any possibility to release the product with an error. So the client can always be sure that the update will not affect the project’s performance.

• Code assembly and packaging

From now on, the developers will not need to connect to the project production server and to rebuild the project on a production service with trembling hands. The users will not see a page of technical maintenance during the site update due to the “hot swap” technique of containers with deployed applications inside.

• Open reporting

As soon as we add the client into a repository, he has the access to self-monitor all the testing, assembly and product application delivery.

How to secure your release?

Where can a problem occur?

- You should understand that automated unit tests and a single environment simply fix the result of code execution in certain places, and prevent any integrity violation in the future. However automation is undesirable or even impossible in cases where the data should be inserted manually. For example, we will never be able to automate the user-friendliness of the application.

How to protect yourself from logic errors and bugs?

To eliminate any deployment errors completely it is a good idea to apply a combined approach to every iteration of product development. Our CHILLICODE team releases projects in 5 steps:

1. When a new feature is made, a developer creates a request to merge a new branch into the main branch of the application;
2. Before merging our project team leader checks the quality of the code and in case of any problem sends the code for revision;
3. When the merging request is accepted, the application goes through several steps of auto testing, code quality analysis and then we deploy it on our staging server;
4. Our QA specialist makes an extra check of all the application functions on staging servers before its presentation to the client;
5. When we receive client’s approval of all the edits and reviews we send the application to release.

What if a critical error was left in the code and went into prod?

For this reason we always save and keep the version tagging system for every release and we can easily roll back to the previous one in case of any critical situation without any need to manually remove the code sections with errors and deploy the application again.

In total,

While working with CI/CD we know how to:

• cut deployment actions up to one click,
• reduce the risks of potential errors,
• automate unit and regression tests,
• ensure high code quality control,
• contain the applications and eliminate differences between the development environment and the runtime,
• make it possible to instantly roll back the application version in case of any serious problem,
• reduce the total development time of 10–20%.

Implement CI/CD in your projects, as we do it in our CHILLICODE agency. If you still have any questions, do not hesitate to contact us, we will be happy to give you more details.