Today, there are still too many manual actions during the lifecycle of our applications. In this post, we will try to move towards simplicity and efficiency to skim off everything that creates difficulty.
First, we need to choose tools:
A standard and current version control system: GIT
The best way to make life easier is to use the most standard tool possible. By doing this, we have all the necessary support to help us the day we have a problem, or a special case to solve. Fortunately, we have one at hand, moreover free and open source, GIT.
I’m generally not for telling everyone to switch to a single tool, but this one is virtuous, common (even essential), rich and easy to set up.
If you don’t know how to set it up, you can turn to github.com or gitlab.com which offer two hosted solutions that have free services, ideal for getting started. In a second step, I would advise you to install gitlab at home, or on your preferred cloud. You will find the necessary resources to do this at gitlab.com or at bitnami (which provides ready-to-run virtual machine images).
A simple organization of your code repositories
Once we have the version control system, we need to know how to organize it. In the following, we will continue with Gitlab.
Simplified production deployment means eliminating all the rough edges that will prevent our project from sliding on its rails. This may seem like a mountain on some projects, which makes one wonder if the game is worth the candle, but it’s a prerequisite.
Break down your applications into unitary microservices
A simple rule: one repository, one application. If your application contains a web part and several binaries, split them into different repositories. If several applications share part of their code, but are independent, move the common trunk into a new repository that will become a library. Or duplicate it while waiting to sort things out.
If you can’t do it on your old monoliths, simplify them. Break out parts that will become separate microservices, and therefore new applications.
If this still seems too utopian, do it first, and right now, for new projects.
Complexity makes costs explode
Even if you feel what I’m proposing as an injunction and don’t see the point, tell yourself that complexity at all levels generates the most constraints in information systems. For decades, we’ve created technical debt at all levels. We’ve put complexity and interdependencies in applications where it wasn’t needed.
The result today leads to applications for which maintenance has become impossible and production deployments risky. We end up with codebases where part remains obscure and no one dares to touch, and unpredictable behaviors:
This is this unacceptable part of loss of control over applications that we accept because we can’t do better.
It’s the famous: ‘As long as it works, we don’t touch it’
Yet there’s a basic idea to follow: divide to better rule
We must simplify to make things manageable. It will take you time to untangle the balls of wool, but when they are, you will see more clearly and maintenance will be facilitated by a factor of 10.
Some rules to observe:
- No database sharing. If several modules use the same database, create an API in front of the database and query it from other applications.
- No file or config exchanges via the file system: This assumes your applications are on the same machine and prevents scalability.
- Use MoM (message-oriented middleware) to transmit messages between your applications.
- As much as possible, use APIs and sockets for calls between applications.
Decouple deployments between elements that have no relation
You deploy your release every month but you haven’t touched a module for 6 months? Why build and deploy it? Why run tests on it if it’s not impacted by the rest of the code? (Because of course, as you’ve untangled the balls of wool, you know there’s no impact)
You’re making a cosmetic update on the front? No need to rebuild and test the backoffice. So not necessarily need to redeploy it either. So development cycles are not the same. If needed, you can synchronize production deployments, especially if the data format changes in the backend and impacts the front. But this will be a feature deployment.
The old-style production deployment that lasts up to 8 hours (as I’ve known) had its heyday long ago and this hell must be forgotten:
By breaking down applications into smaller and simpler modules to manage, by dividing production deployments by application, and by only doing those that are necessary, we mechanically reduce the time spent on production deployments.
We also reduce the complexity of these production deployments. As well as that of test phases. The virtuous circle is set in motion and this simplification of tasks gives us the possibility to automate them.
Making production deployment a non-event
When we’ve eliminated the essential risks related to the complexity of our production deployment, a large part of the precautions until then taken by teams become superfluous. Tests mechanically cover more important cases and we’re more confident about the outcome.
It remains important to maintain the calendar of production deployments of different modules, but there’s no longer a need to have dev, system admins, project managers and representatives of each team live to attend on D-day.
Pushing the judgment further, no more D-day either.
Continuous deployment is when production deployment can happen anytime, whether by feature or bugfix. It also allows easier identification of where the problem comes from in case of issues, because we put less new code into production at once.
now, we will look at the pipeline (CI/CD) itself, but that will be in another article.