Each time we modify something on a Linux server, it means we have deployed something. Let it be a minor change to /etc/httpd/conf/httpd.conf/ or a completely new application which has been recently installed or configured. It is a deployment and we need to verify it.
That kind of verification is not complex. In case the change to httpd.conf is minor, we simply need to test that specific change and make sure it is working as expected.
Here at LinuxAPT, as part of our Server Management Services, we regularly help our Customers to perform related Linux system queries.
In this context, we shall look into how a system admin can go through a post-deployment verification in a Linux environment.
Why the need to do pre-deployment and post-deployment checklist in Linux ?
A system admin should have a pre-deployment and post-deployment checklist as an absolute to avoid unwanted circumstances. A checklist also helps teams in a way that they know what is going to happen. Here is how we are going to do it.
Pre-deployment Checklist
- Make sure that it is in the knowledge of everybody that what is the scope of change. You might be working to apply a simple configuration or modify a file, but rest of the team might think you are deploying entirely a new application.
- Make sure that the change which is going to be applied is gone through necessary testing in a development or staging area. It is always better to test the upcoming system level change to prevent any outages.
- Backup all relevant data. In case of minor changes, it will suffice to copy the particular files before editing them. On other side if you are making a major change then full backup of server is required.
- Depending on how your organization manages Linux servers, you may need addition precautions to add in your checklist.
Post-deployment Checklist
- Always test the change. This could be checking if a web server is running properly such as Apache answering on different ports, or verifying a new SSL certificate for your freshly deployed application.
- Testing other things involved in the change. We can have an example scenario here like, you are deploying a new SSL certificate then you must make sure that no other SSL certificates on the system are affected.
- Allow developers to thoroughly examine their services. It doesn’t matter if they are directly involved in the change. Many things go wrong on production servers often. It is always better to be on the safe side.
- Rollback changes if something does not go right. Try to troubleshoot the issue. If nothing works, it is better to roll back your server.
- If all the tests are passed, you can mark the deployment complete and celebrate the success.
[Need assistance to configure Nginx on your Debian Linux System ? We can help you. ]
This article covers how to avoid bad circumstances while directly working with Linux servers where a single careless change can take the system down. If you follow the above checklists and fully examine your tests then you will be able to conduct better post-deployment verifications.
