Recently, our team participated in the Adidas Stations Circuit. And how could it not be, I was there. The thing is, I expected to perform much better in the race, but what happened was that I saw that running on asphalt is quite different from running on a treadmill. And what does this have to do with releasing a production version? Let’s get there.

Most people when they want to perform well in a street race, they train in a gym. In this environment, you run on a treadmill where you can control the speed you want to run, and in some you can even control the slope of the terrain. After a period of training, you are already able to know how your body responds to the effort made. You know if you can run faster or slower, and it’s all controlled by you through the treadmill’s display. When we move to the asphalt, all that control disappears. You don’t know if the ground is smooth or not. You don’t know the exact speed at which you are running and it may be that these factors hinder your performance and it is much worse than what you have at the gym.

The same happens with systems when they are in the development environment and move to the production environment – ​​or homologation. Developers build the functionality of a system into the development environment. They are used to working there and all the problems that were possible to be found have already been solved. The system is adapted to run there and the environment is always configured according to the latest version of the system, since this is where evolutions take place.

When it comes time to release the production version, the story changes. This version, which is working perfectly in your local environment, will be transferred to another environment and will be accessed by other users. This can and will generate unexpected situations that will have to be worked around quickly and efficiently, so that users do not have their access to the system harmed. and why this happens? Precisely because it is a different environment, on a different server, with different configurations and infrastructure. You don’t have enough knowledge of this environment, and its users, to know what behavior to expect from the system when the new version is there. Therefore, what we can do is to prevent problems from occurring and, if they do, it is possible to recover as quickly and as best as possible. For that, here are some tips:

  1. Simulate the production environment on your local computer: Before releasing a version in another environment, simulate it on your development computer. Have an application server, a database and any other infrastructure necessary for your project separate, with the same configurations and structures that exist in the production environment. Often, when releasing a new version, you need to change a configuration or a database table. And, oftentimes, we forget to make this change in the target environment. Testing the new version in this simulated environment can prevent problems from happening in the production environment.
  2. Keep a backup of the version that was in production: Making a backup of the version that is currently in production, before releasing the new version, is highly recommended. This strategy avoids problems such as taking the system down because the new version had errors in the release and you have no way to recover the previous state quickly. In these cases, when you have a backup, the new version is quickly removed from the server and the old version is placed again until the problem that occurred is resolved. Never think that this will never happen to you. As stated above, the production environment is a different environment and unexpected situations may occur.
  3. Create tags of the version that will be released in version control: being in a different environment and with different users, it is possible that bugs appear and depending on their severity, it may be necessary to fix them for yesterday. If you created a tag from the version that was just released, you can correct it and release it again without submitting code related to functionality that is not yet ready. However, don’t forget to replicate this change in development code. If this is not done, new versions will have the same problem again and this will generate rework for the team.
  4. Keep a file with the scripts of changes made to the database: not always, but sometimes it is necessary to change the structure of the database when making a change or developing new functionality. If it is customary for the team to keep a file with the change scripts for this structure, identifying which change corresponds to which version, it becomes easier to identify what should be changed in the database used in production. A good practice is to make the scripts in this file generic, that is, queries should not be made considering specific values. Remember that even if the data of the two banks are the same, it is possible that the ids, for example, do not match. And, if in the script the queries depend on them, this will generate a big problem. Also, this practice helps in cases where you create a new database from the schema_create at the beginning of the project and you need to adjust its structure to the current state of the project.
  5. Keep a history of the updates made to the environment configuration: similar to the item above, it is always good to keep a history of the updates made to the environment configuration. This allows a kind of tutorial to be created to help set up a new environment.

These are simple but very effective tips. Just like when we run on asphalt, we have no way of predicting exactly how the system will behave when it is in an environment in which it is not used to working. Adding these steps to your deployment process can go a long way towards avoiding unexpected problems.