The importance of automated deploy and releases (including config files)

Mauricio SilvaConfig, ReleaseLeave a Comment

Most companies do not give the importance due to automation of their development processes. Routine tasks such as build, deploy and release new versions of the application are done completely manually. All these tasks should be simple and executed several times a day, but in reality they are avoided because of the high cost of their execution and for fear of breaking something into production.

Deploy means making the application available for use. For example, a manual deploy process may consist of exporting a WAR in Eclipse, accessing the Tomcat administration page, and uploading the WAR.

These manual, time-consuming and problematic development processes are already so deeply rooted in corporate culture that they all consider normal practice.

The difficult way is the standard and teams can not see that there is room for improvement. Companies are paying too expensive and delivering software less often.

Within the automation process, the configuration files may also have their automated publishing within the process of automatically publishing the releases. This will give much more security than manual deploy. If there are components with configuration files that require different values based on the target environment, you can create a token for the configuration files.

Manual builds bring inumerous risks to the project and automating it will help you heal most of them!

Do not automate only the build but also deploy

Although the build is already common practice, deploy, which is a critical process for software delivery, is still left out and done manually on company or client servers. To make matters worse, the deploy of the application usually stays in the hand of only one person, who in turn has all the step by step in the head. It simply leaves the company that the various problems related to knowledge center appear.

For most companies and projects, the deploy process is something very simple. It is only a list of steps that must be performed in a particular order. If you stop for a moment and write these steps in a TXT file, chances are you end up with a list very similar to the list below:

  • run the build to generate the WAR;
  • upload the generated WAR to the production server;
  • stop Tomcat;
  • delete the old Tomcat WAR;
  • copy the new WAR to Tomcat;
  • restart Tomcat;

These steps may vary depending on the application and production environment, but overall, this script does not skip much. Although simple, running each step manually besides time consuming, opens up gaps for silly errors, such as forgetting to delete the old WAR or even forget to stop Tomcat first of all. Like any manual task, the higher its frequency the greater the chances of errors.

Because it is a time-consuming and risky process, it is common for it to be done less often, which runs counter to the agile principles in which it says: if the process bothers you then do it more often.

Be patient, after you mature your deploy process you can invest some time to apply standards that reduce the risk of deployment, how to evolve the database schema, rollback in case of error, securely publish configuration files, among others.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *