A pragmatic and efficient approach

Deploying by following DevOps practices helps to minimize future issues. A solid DevOps foundation provides developers with necessary methods and tools for efficient application design and continuous maintenance. It includes efficient development practices, a method for validating changes, CI / CD pipelines, infrastructure as code, telemetry and alerts, to name just a few features of this approach. If all the tools are in place, development teams gain the following four major benefits:

• Reduce risks by deploying applications more frequently due to their smaller size.
• Gain visibility on the performance of applications, and thus detect problems before customers face issues with applications.
• Identify problems before they happen by having environments to test applications before going into production.
• Increase speed and reduce development costs, because the earlier a problem is found in the process, the less expensive the fix will be.

“Having a solid DevOps foundation helps to deliver production value faster and more reliably. The notion of DevOps is complex and requires a thorough understanding of various technical aspects involved: software development, its delivery, its monitoring in production, and its maintenance. We must not forget that its objective is to unify software development (Dev) and IT infrastructure administration (Ops)"
Julien Maitrehenry, CEO & co-founder of Kumojin

OUR BEST PRACTICES - THE KUMOJIN RECIPE

• Closely follow the 12-factor development methodology - https://12factor.net/
• Carry out automated tests (unitary, integrations, etc.)
• Mandatory peer review process
• Local developments and tests with the use of only local resources
• Encourage training and technology watch
• Favor open-source solutions
• Avoid locking into a vendor / being cloud environment agnostic

OUR RECOMMENDATIONS

A DevOps approach should be a step-by-step process. Before thinking about automatically deploying to production, it's important to ensure that testing tools are in place to limit the risk of bugs during production.

Changing the code should be executed through the following steps:

• Design
• Approval of the change
• Putting change into production

During the design stage, the developer must, at a minimum:

• Test the change manually and/or automatically
• Add automated tests (unit test and/or integration test) to validate the change
• Validate that all existing automated tests continue to function well

At the approval stage, the development team must:

• Validate the change by reviewing the code (ideally, peer review)
• Suggest improvements, if necessary
• Make sure that the automated tests work and do not return errors (and, ideally, have a tool to automate this task - Continuous Integration)
• Ensure that the project documentation is always up to date (README, wiki, etc.)

And, at the last step, the production of the change, it is important to validate a few points:

• Test the deployment in a test environment (staging)
• Make sure that if the application needs new dependencies and/or configuration, the environment is ready

For this last step, it is possible to automate using the best practices of Infrastructure as Code, as well as the automation of deployments (Continuous Deployment - CD). For example, if there is a need to change the database schema, it should be a part of the application/deployment process to do so and not a human operation. The more automated the process, the lower is the risk for a human error.

As previously explained, it is crucial to follow the step-by-step approach. It is extremely dangerous and, ultimately, counterproductive to deploy to production before having automated tests of a validation process.

Our second recommendation would be to avoid focusing on proprietary solutions. There are several advantages to this. First, it is easier to find expertise for a popular open-source solution than for a proprietary tool requiring a license. Second, it is possible to rely on a community support for an open-source solution.

Third, it is worth keeping in mind that we are in an ever-changing world and, therefore, it is difficult to predict the future as well as the evolution of methods, technologies, or suppliers. Finally, proprietary solutions (such as #Cloud, for example) require increased vigilance for possible drawbacks, which is time-consuming and inefficient.  

“The objective is to remain flexible, and not to put yourself in a difficult situation. In the past, I was working for a company that decided to change cloud providers. From the start, my team remained cloud-agnostic by choosing solutions like #Kubernetes, #NATS, and #OpenTelemetry. This allowed us to migrate our applications very quickly. "
Simon Bernier, FullStack developer, Kumojin

KUMOJIN VISION

One of our mantras is to be pragmatic. When the time comes to start a project, we always follow the step-by-step approach. This allows us to deliver the product quickly and without any bugs. To do so, we put in place the DevOps principles explained above: setting up validation tests, going through a peer review, as well as ensuring continuous integration and deployment. It is worth noting that the staging environment is always added closer to the end of the development, and the integration tests are also executed on final stages of the project.

It is important to estimate the amount of effort that is necessary to be invested to achieve results efficiently and quickly. When you start working on a product from scratch, implementing good practices right from the beginning is much less expensive than doing it afterwards! However, it is also impossible to predict with 100% certainty all the tools that might be necessary to successful realization of the product.

If you look forward to implementing the DevOps philosophy in an existing project, you will have to start by looking at the needs of the team and to go step by step: are there tests in place that test the viability of the project? Is there a validation step before effectuating a code change? And, based on the obtained responses to these two questions, you will be able to estimate what is doable and realistic.

Finally, we should not forget the most important: having fun! We believe that any development team must have fun when working on a project, and DevOps should be there to help and support the teams.