Clever Planning: Pre- and Post-Deployment Commands

Why do you use a tool like DeployBot? Hopefully, one answer that comes to mind is: “To automate things!” DeployBot can take care of tasks which normally take up a lot of your time – time you can spend on coding. In this article, I’d like to introduce you to a clever DeployBot feature: pre- and post-deployment commands.

Before we look at some examples, let me point out that this feature only works for file SFTP deployments. A quick reminder: DeployBot offers two kinds of SFTP deployments: file deployments and atomic deployments. File deployments upload files straight to a specified directory. Atomic deployments work differently. They maintain a special directory structure on your server that allows DeployBot to store last N releases and switch between them using symlinks. 

In atomic SFTP deployments you can define post-upload commands, but no pre-deployment commands, since atomic uploads are non-intrusive. Have a look at our corresponding article in our knowledge base if you want to find out more about the difference between SFTP and atomic SFTP. 

What kind of Commands can I run?

First, let’s talk about the term “command”. What exactly does it mean in this context? I’m basically talking about three different things here:

• Operating System Commands 
• Scripts
• Other Executables

Important: Please keep in mind that all commands, whether you run them before or after the deployment, should be able to run stand-alone, i.e. they shouldn’t require any user interaction. 

For example, it’s totally fine to enter something like systemctl restart <service> to restart a certain service on your server, whereas a command like this is kind of pointless:

sudo less /var/log/apache2/access.log 

The pager less will start and display the content of the log file, but it will not be visible to you or any other user. Also, you normally hit [Q] to quit the less programm which you won’t be able to do. As a result, the deployment will go into a waiting state until the less process has been terminated or the user has cancelled the entire deployment process. Alternatively, after 40 minutes the deployment will fail with a Timeout Execution error.

Pre-Deployment Commands

So, let’s look at commands you can run before you start the deployment process. Maybe you want to put a website or a web application into maintenance mode, maybe you need to check some conditions to see if the deployment should proceed or stop. You can also stop a web or database server:

sudo systemctl stop apache2
sudo systemctl stop mariadb

Are you running a PostgreSQL database and want to create a database dump before deploying? No problem, PostgreSQL offers the pg_dump command:

pg_dump dbname > dumpfile

This will generate a text file (dumpfile) with SQL commands which you can feed back to the server later to recreate the database (dbname):

psql dbname < dumpfile

It restores the exact same state as it was at the time of the dump.

The mysqldump command for MySQL/MariaDB works similarly: it dumps a database or a collection of databases for backup or transfer to another database server (not necessarily MariaDB or MySQL). To find out more about the respective dump tools and their options, have a look at the manuals:

• MariaDB/MySQL handbook
• PostgreSQL handbook

Alternatively, you can define a command which sends out an email or some other notification to your team or provider. In any case, with pre-deployment commands you can do all this and much more.

To define a pre-deployment command in the DeployBot dashboard, open the server settings of your SFTP server and scroll down to the section Run shell commands before deployment. Enter one or more commands in the field below. These commands will run before the deployment takes place. Remember that a non-zero exit status of a command will halt the deployment and mark it as a failure. Don’t forget to scroll all the way down and click the Save changes button.

Post-Deployment Commands

The same server configuration dialog offers a section Run shell commands after deployment. This is where you store your post-deployment commands. Again, a non-zero exit code will mark the deployment as a failure.

As you can see, each line contains its own command. The example shown in the screenshot would be split up and run as two separate commands. Note the && operator in the second line: this shell operator makes sure that the ./runTests script only gets executed if the previous command (cd scripts) was successful.

Of course, you can use this DeployBot feature to enter commands for re-starting a web server or a database server, for updating a database or moving, copying or deleting files. If you need to clean up some log files which have been generated during the build process, this could be done here as well.

Here are some more examples for post-deployment commands:

• Check if a service is running: systemctl status apache2
• Restart or reload a service: systemctl restart/reload mysql
• Check the log files for your Nginx web server and PostgreSQL database server: sudo journalctl -u nginx -u postgresql

Of course, you can send the results of the journalctl command to yourself or someone else using the mail command:

sudo journalctl -u apache2 | mail -s "Apache Logs" me@email.com

As you can see, there are endless possibilities and you can combine typical shell programs and commands as you see fit.

More Automation, less Work

DeployBot supports you during your entire CI/CD workflow. Pre- and post-deployment commands for SFTP servers are just one example for automating typical tasks. Thanks to this feature you don’t need to log into your server manually to run a script or command, let DeployBot do this for you.

Do you have suggestions for more pre and post-deployment commands? Do you run a clever script on your servers which you would like to share? Let us and other DeployBot users know and leave a comment!