Introduction
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.
In a hypothetical dynamic website, the files that it consists of can be divided into three large families:
1. The files that generate the website pages — these are files that contain the code that generates the pages (depending on the chosen programming language they can have various extensions: .php for php, .rb for ruby, .py for python, and so on). We should consider that these files can potentially be different in each code release.
2. ‘Assets’ are files that are not generated at each request, and are usually javascript files, css files, images and fonts. These files may not be subject to changes between releases.
3. Other file types. Depending on the programming language used, there could be other file types present (such as configuration files, files containing credentials, etc.). It’s good practice NOT to keep these files (especially those containing credentials) in the repository. This is so that if an unauthorised person gained access to the repository, the access data would not be compromised.
Managing assets with Minify and unification
These days, in view of the heterogeneous nature of the market and the variability of the connections available (think of the difference between the optical fiber connection used in some homes and the 3G connection used in mobile phones), web developers should also take responsibility for site optimization — for the specific purpose of making it accessible to the largest possible number of people, regardless of what type of connection they have.
One aspect of web development that makes a big difference is the optimization of ‘assets’, to ensure that they are as few as possible and that at the same time these files are as small as possible (smaller = less time to download).
To achieve this, it is good practice to unify the files as much as possible and then minify them during deployment. Regarding unification, the concept is quite simple: you take the N css files and merge them in a single large css file. Next, still during deployment, you proceed to minify the file, removing all non-essential characters such as spaces, new paragraph signs, etc.
The gain in performance is considerable — currently, this is best practice that practically everyone adheres to.
As we mentioned before, a website also contains “sensitive” files that are not found in the repository but which need to be on the server for the site to function correctly.
During deployment, these files must be located where the website can find them, so that normal function can be achieved. This operation is normally performed via symbolic links.
Another crucial operation that a good deployment system should take charge of its database management. Supposing that the new release of our website uses a new column (assuming we’re using a relational database), the deployment system should deal with creating this column before the new release is made accessible to site users.
It is not acceptable (or should not be acceptable) for anyone to be able to gain access to the database to do it manually.
Once all the above operations have been completed, all that remains to do is restart the website to ensure that the new release is ready for use. It is not stated anywhere that restart is necessary (it depends on the technology being used), but if it is necessary our deployment system must be the best candidate for the job.
Giving feedback on all completed operations
One more crucial aspect of a deployment system is how it gives feedback to the user requesting a deployment. It is essential for the system to clearly report the operation’s progress, and above all to inform the user if any part of the operation has been unsuccessful.
Email me when Developers How-tos publishes stories