Webmasters Gallery

Let’s set the scene. Say you are a web freelancer and are almost finished with a client’s new website. Over the years, you have learned the hard way not to edit the files directly over FTP. It’s too easy to make breaking changes with no record of what changed and who did what. Nowadays you are using Git to manage the version of the files.

Why use version control?

There are many benefits of using a version control system for your projects. Even if you’re a very organized person, you still might get confused with a naming system like `index-2017-01-12.html` or `header_image_final_final_v2.svg`. Is it really final? How do you know what exactly is different between these versions and the last?

A version control system (VCS, like Git) enforce that there is only one version of your files at any given time. All past versions of files are neatly packed up inside the VCS. When you need it, you can request any version at any time, and you’ll have a snapshot of the complete project at hand.

Every time you save a new version of your project, your VCS requires you to provide a short description of the changes. Additionally (if it’s a code/text file), you can see exactly what has been modified in the file’s content. The VCS helps you understand how your project evolved between versions.

Deployment / Uploading

As useful as a VCS is, it doesn’t directly help with uploading files to a live website. (We’ll refer to that as deployment.)

Deploying files can be very easy. Use an FTP client (e.g. Transmit) to upload files via FTP or SFTP straight to your server. The initial release of a site is especially easy: just upload all the files.

When you make changes to a site, you also need to upload files. But… which ones? Do you always remember which files you have changed? If your panicked client calls to tell you that the site is broken, do you know what changed the last few times you uploaded files?

If you are using Git, it’s easy to see. But still, Git doesn’t do deployment, and manually checking which files have changed and moving those is error prone and tedious. You still need a smart way to upload and deploy your changed files only.

So what other options do you have for deploying files? One option is also installing Git on the server. Then just like you push and pull from your Git repository locally, you can pull from that repository on the server and the server will pull down the latest changes. This isn’t an option for everyone, though. It will require shell access to the server and that just isn’t possible on many shared hosting solutions.

Another possibility is to rely on third-party cloud services like DeployBot, Springloops, or Beanstalk. None of these choices are bad, but there are potential downsides:

• There are monthly or annual costs to these services, whether you are actively using them at the moment or not.
• Setting up external Git repositories may take some time and can be complicated.
• There is also the increased risk of relying on a third party service. The deployment service can be down at the moment you want to deploy.
• The speed of the deployment is dependent on that service. There may be a long queue of other deployments before yours.

A Look at GitFTP-Deploy

Let’s take a look at my alternative: GitFTP-Deploy. GitFTP-Deploy is a native macOS app that only uploads the changed files (through SFTP, FTP or FTPS) since the last deployment. You don’t have to remember which files you have changed, added, or deleted.

Since GitFTP-Deploy reads what have changed from your local Git repository, you also get in the habit of using a Git for your project: once a file is committed, it’s also ready for deployment.

Another feature which could ease up your deployment is GitFTP-Deploy’s ability to run pre- and post-deployment scripts. Are you using a JavaScript compiler (like Babel) or CSS preprocessor (like Stylus)? Are you concatenating and compressing assets? Running these tasks can be make automatic by the app.

Other times it can be a real time saver just to commit the last changes, and it’s automatically pushed onto the server, just with a single Git commit command.

Getting started

In less than two minutes you can start to deploy your files.

1) Create a new site

2) Point to your local repository and select which commit you want to start deploying from

3) Setup your server connection

4) Click Deploy

Maybe your workflow is a bit more complicated? You need more power?

You can specify scripts to be run both locally and on your server, before and after uploads. For example, before uploading, you may want to run your favorite JavaScript compiler or a Gulp script that concatenates and optimizes your JavaScript files for production.

Or perhaps you are using a workflow with another task runner like Grunt? Grunt can also be configured to help you with optimizing images, compressing scripts, compiling preprocessors, and countless other things.

The ability to run tasks can be quite powerful. For example, even WordPress has WP-CLI, meaning you could script out things like database syncing and settings updates with your deployment.

Other Notes on Usage

If you prefer not to have build files under version control, you can add this folder to “always upload”.

Using GitFTP–Deploy does not mean that you cannot use GitHub or another third-party hosted Git repository service. Just make sure to pull the changes from there before deploying.

Team Usage

While GitFTP–Deploy is not exactly built for teams, you can still use it. The easiest way it that one person handles the deployments. Another more advanced option is to run GitFTP-Deploy on a server.

This way may not work for large teams, and commits are done through many different individuals. However, GitFTP-Deploy will attempt to check which branch and commit that which was last deployed.

GitFTP-Deploy is a post from CSS-Tricks