The subject of web development is a universe in itself, embracing a multitude of different technologies — each of which has its own particular method (and sometimes more than one method) of deployment.
In this post, we’ll discuss the various operations performed during a deployment process, while trying to keep as generic as possible so as not to get caught up in the details of any particular technology.
Once upon a time
At the beginning, the concept of deployment did not exist in anything like its present form. At the time when websites were composed of a set of simple html pages, deployment consisted simply of uploading pages (often via FTP) onto the server, and more often than not the operation was carried out manually by the web developer.
As the web started to become an everyday feature in people’s lives — and websites started to become more complex — it became clear that uploading files via FTP was no longer practicable, motivating web developers to look into new methodologies.
Today, websites have reached such a level of complexity that the very idea of carrying out deployment via FTP is likely to raise a smile. In the last few years the web has evolved hugely, and now setting up a website involves dealing with a whole new set of procedures that weren’t needed not so long ago.
What should happen when you deploy an application
Nowadays, deploying an application requires a long series of operations — we’ll discuss the main ones here.
Getting the latest application code review
As you may well have guessed, this operation is the most important one. How this operation should be carried out depends to a great extent on which tools the development team has decided to use. Today, it’s standard procedure to use an SCM (Source Code Management) tool. The one used most often is Git, so assuming that Git is being used, during a deployment we must ensure that the server downloads the latest code review from the Git repository.
When the server downloads the latest code review it stores it in a folder. It is considered best practice to ensure that the server stores N reviews, so that rollback can be operated at any time — in other words, so that a version that was replaced beforehand with the more recent version can be put back online. The reason for doing this is quite obvious — let’s suppose you’ve just performed a deployment and you encounter an issue. Instead of trying to correct it quickly and carrying out another deployment, you’ll be able to change the situation back to how it was before the deployment responsible for the issue.
Want to read more? Read the full article on medium!