Surely, FTP site deployment is still one of the most common ways you’ll come across. Sometimes, however, it can be a nice nuisance, especially for projects that are constantly evolving and changes are uploaded to the server regularly. In these cases, you usually have the choice to either unnecessarily upload the entire project to FTP again (which will be much more time consuming, among other things) or manually select the changed files and upload them only, one by one, to FTP.
I did the second file for quite some time, but it had several disadvantages. The first may be, for example, that there is a real chance that you will forget to record something. Another problem might be that the files are uploaded sequentially while the application is running, which may become inoperable for a while because the files are interdependent.
Automatic PHP FTP deployment
A simple but fully functional solution is to use the & nbsp; FTP deployment & nbsp; by David Grudl. This is a PHP library that provides you with smart deployment of changed files to remote FTP. Files are compared using MD5 hashes of individual files, so only the changed ones are really loaded after starting the deployment.
An important feature of uploading files is that the files are first uploaded to FTP with the; .deploytmp extension, and only when they are all uploaded are they renamed to their original name. You will especially appreciate this when uploading a large number or large files, as uploading the files themselves will not slow down the application and renaming the files is much faster operation than uploading them.
All you need to use is to have PHP installed (eg using Wamp) and the php_ftp extension activated in it.
Deployment.ini configuration file
You can configure the entire deployment process within a single & nbsp; deployment.ini file. The only mandatory item in it is the configuration of the remote server – the setting of FTP accesses to the remote server. However, in the case of a more complex configuration, this file may also look something like this:
In addition to setting access to FTP, we can set, for example, which files will be ignored during deployment, actions that will start before starting the file upload (enable web maintenance mode) and which will start after the upload is complete (disable mode maintenance) or also deleting the application cache folder. For complete configuration options, see the documentation .
Ignored files include all files and folders that are not required to run the application on the server. These can be pre-merge CSS and JS source files, cache folders or logs, but also configuration files and .htaccess files that can vary across environments (these files then need to be uploaded manually).
Test mode
An important and frequently used option is to set the test mode, which is done by setting the & nbsp; test parameter. & nbsp; If test = yes and we run deployment as usual, we can see which files are uploaded to FTP and which will be deleted – but in reality nothing will be done. This can certainly come in handy from time to time to make sure that the correct files are uploaded to FTP and that nothing important we don’t want is deleted.
Setting up deployment for multiple servers
We often encounter a situation where we have multiple servers for one site – typically development (testing) and production. There is definitely nothing stopping us from creating two configuration .ini files and using the one where we want to upload the files. The problem is that a lot of settings are the same for both servers and quite often they will differ only in the access data. And if we add to this a situation where it is not appropriate to version these configuration files with stored FTP accesses in GIT for security reasons, the problem is to maintain the configuration with each other, even more so when more developers are working on the project. In reality, when one developer changes the configuration and adds a new ignored folder, for example, the other developer may not notice and do not add the folder to the ignore.
But solving this problem is not complicated. We still use one main deployment.ini file, which contains the configuration, which will always be the same for all servers. In addition, we’ll create another configuration file & nbsp; deployment.example.php , which will look like this:
The file does nothing but load the configuration from the common deployment.ini file and merge it with the configuration in the local file. In this case, a field with FTP access configuration is already prepared here. However, since there are no real FTP accesses in any of the files, it is not a problem to version them in GIT.
Then, when I want to set up deployment for the development server, I copy the deployment.example.php file and name it deployment.dev.php. For a production server, this could be, for example, deployment.live.php. I will add functional accesses to the given FTP to these files, but the files will be ignored in GIT in order to prevent security problems and leaks of accesses to FTP.
Start file deployment
Finally, we come to the actual start of the FTP deployment. If you have a library installed via composer (which I recommend), the easiest way to start deployment is with the command:
Create a composer script
The second option and a slight simplification may be to create a new script within the scripts section of the composer.json file.
Deployment is then started with the command:
FTP deployment using Grunt
The third option that I use most often as a frontend developer is to use Grunt. I will create a new task in Grunt, which will run a compilation of assets (CSS, JS) before deployment, upload files and open the URL of the server where the website was uploaded in the browser – so I can immediately see if the application is running and can test it.
For this I use node packages grunt-shell and grunt-open (for this, of course, tasks for compiling assets). The configuration in gruntfile.js can then look like this:
I then start the whole process simply with the command (or even better directly in PHP Storm in the list of Grunt tasks I start deployment with the click of a mouse):
The great advantage of this solution is the simple start-up and the possibility of linking the deployment to any other tasks.
Leave a Reply