Development Principle 4: How to implement correct deployment process?

The deployment process is an essential part of any software project. It is a key part of creating and growing your project. Without deployment, your project wouldn’t reach the state it was intended for.

Regardless of if you are working on a small personal project or an active large website, deployment must follow a clear process that can be reviewed, repeated, reliable, and reversible.

Making a change in live software is the first step. To build the best version, most projects have a place where the code is stored. This is your “live” code. It should be as stable and bug-free as possible.

You should make changes to the code elsewhere. This could be on your own machine or on a server that isn’t visible to the public. When we say “deployment”, we mean the process where someone takes the code and places it on the live site.

Now, let’s cover three tips you can utilize to ensure your project has a happy and healthy existence. These tips assume that your project uses version control software. Github Flow is a highly recommended approach. We have written about it in another post.

Reviewed

It should be easy to review the code you’ve modified. The modern version control software can be used to see which lines have been modified in the last commit or change. It also highlights lines that have been added or removed in Green and Red colours. Each commit should be easy to review. It is better to fix one issue than to commit the change to fix the other. These are known as Atomic Commits.

It is easier for developers and reviewers to understand the changes and see why. This can help with tracking long-term issues in your project. 

Repeatable

Every change should be repeated in your code deployment process. The deployment process should be identical, regardless of whether it is a simple change to the user interface or a new feature that you’ve added to the application. The code should be easy to deploy to a server, or to the build branch. This process should be easy for everyone on your team to follow and allow their code to seamlessly transfer to the live environment. It would be ideal to create a deployment process that everyone on your team can follow, so the results are exactly the same each time.

Reliable

It is easy to think that your code will do the same thing locally as it does in a development environment, though this isn’t always the case. It can be difficult to predict what will happen once your code is finally released to the live environment. For example, there may be differences between the development environment and the living environment. It is important to ensure that your process is reliable right down the wire. You should ensure that all environments for code are identical. Also, ensure that your code changes do not depend on specific environment variables or package updates without clear documentation.

This will allow you to develop the code with a “what you see, is what you get” mindset. This will allow you to be confident that the code you have written will work as you expected it to when it goes into production.

Reversible

Even the best coders make mistakes, and it is important to fix any bugs that may have slipped through to the production code or your latest build. Some bugs can take several days to fix. If that happens, it is best to “roll back” any changes or to reverse the code to the original state before the change was made.

This might not be as easy as it appears. Some projects have environment variables and configuration files that are not part of the version control. These variables would need to be modified when the code is rolled back. These changes should be documented in your commits or anywhere else that standard documentation is for the project.

Automate your Deployment Process

Some deployment processes require users to compile certain code, compress images or include a “production” folder that’s not used for testing. Coders make mistakes, and it is possible for someone to forget to add the folders or compile the new code.

Automation tools can greatly reduce the chance of these things getting missed. Ansible is an excellent example of an automation tool that can handle everything before a deployment. It can test, compile, and push the code for your use.

Do not allow automated processes to be excused for being late. After you have confirmed the deployment with your eyes and possibly performed post-deployment testing, it is considered complete. You should always be prepared to help if the script fails.

Conclusion

These guidelines will help you make your deployment process more manageable, repeatable, and easily reversible. Your project will live a happier, more bug-free existence if you follow these tips!