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
- 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
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.
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 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 (
psql dbname < dumpfile
It restores the exact same state as it was at the time of the dump.
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:
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.
DeployBot is here to help you: it comes with a number of integrations for external tools and can quickly deploy your work to different environments. You can find an ever growing collection of beginners’ guides on our website.
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
sudo journalctl -u apache2 | mail -s "Apache Logs" firstname.lastname@example.org
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!