DEPLOYMENT
When you modify a website, you usually do this locally. If you then want to actually implement those changes on your website, you ‘deploy’ them. You need to do this because your website is not local, but on a server. Deploying those updates can happen in different ways.
(s)FTP
Although often used for small websites, FTP is a protocol that is actually not secure. Because the connection with the server via FTP is clear text, a potential hacker on the network can easily view all data. That’s why there is also a secure variant: SFTP.
Additionally, FTP does not provide version control. Wait, version what? When you choose to make changes to your website locally first, version control is very useful. This ensures you don’t make mistakes in your production environment.
Every change can be saved under a specific name, and you can always go back to a previous version. Compare it a bit to the version history of your documents in Google Drive. Version control also allows multiple people to work on the same project. The most well-known version control system is Git.
GIT
Global Information Tracker, better known as Git, is an open-source source code management system. Predecessors of Git were CVS and Subversion. Git itself was developed in 2005 by Linus Torvalds, who is also known for the Linux kernel. Compared to CVS and Subversion, Git has a major advantage: it allows local changes to be made without a connection to the remote server.
How does Git actually work?
Well, this gets a bit technical.
- First, you create a local 'repository', which is a folder that you convert into a special Git folder using a Git command.
- Then you add your project files to it. You add files that have been modified.
- Each time you finish a small change, you commit this change with a specific message so you know what the change actually entails.
- Finally, you push this to the remote origin or server (Git push) so everyone can see the changes.
A Git pull works in the opposite direction of a push, logical right? With a Git pull, you fetch the latest update from the remote server to work on it locally. All these actions can be done via your terminal, but there are also nice GUIs (graphical user interfaces) to work with.
GIT FLOW
With Git flow, you can take Git usage a step further. Here, you divide your different environments into branches: a different version of the code that has a bit of its own life. For example, you can make and commit changes in your development environment and then merge this code into your staging environment. After resolving any conflicts, the code is merged, and your changes are also applied to the staging environment. The same process can be done for your master or production environment.
To complete your Git flow, the type of changes you make is also divided into branches: features and bug fixes. A feature is the development of a new functionality on your website. A bug fix is the solution to an existing error in your code. It makes sense that a different process is used here: bug fixes need to be implemented much faster than new features. By adding these branches, your development and staging environments always work, and no code ends up there that shouldn’t be.
DEPLOY VIA A SCRIPT FROM YOUR PC TO THE SERVER
Using Git directly from the web server is possible but not recommended. Besides the fact that it is not very secure, it is also not the most practical way to work. It’s better to start from an empty directory, pull your branch into that directory, and deploy from there.
So how should you best deploy? You can use Rsync, a CLI tool that ensures your remote code ends up on the server. Rsync compares the metadata in your files and only updates what has changed.
Magallanes or Capistrano are nice deployment tools that can send the version of the script from your PC to the server. They work with 'releases' and can perform different steps before, during, and after copying the files. For example: preparing images, restarting services, indexing text, and so on.
WHAT DEPLOYMENT TOOLS DO I NEED NOW?
As the words suggest, a deployment tool exists to assist the developer. No tool is strictly necessary, but using them ensures efficiency.
We always start from the developer’s knowledge and needs. For some developers, using Git is already a big step. In that case, we focus on guiding the use of Git and deployment via a script on the PC.
For developers with more deployment experience, it’s important to communicate clearly: What is needed for this project? How many developers are working on it? How large is the project, and what is the budget? Using different tools and applying CI/CD always sounds interesting, and we are happy to assist with that. But the business case must make sense! ;)
