This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Deploying Your Code via FTP, SCP or rsync over SSH
Every piece of code, content, or web page has a final destination where it is displayed or consumed. In this series, I want to go through the simplest and easiest ways to publish your code to its destination, whether its hosted or cloud servers.
I’ll stick to simple publishing scenarios like FTP or copying files in this article. But, stay tuned for part two for advanced publishing methods that handle rollbacks and historical deployment tracking.
Exporting your code or content
First, you’ll want to get a copy of your content from the repository. Here are some examples:
svn checkout, svn export
git archive, git clone
The main issue here is that when you use svn checkout or git clone, a hidden folder of .svn or .git will also be created. This folder contains repository information that you do not want to expose via the web or your production environments. Of course, there are ways to configure your web server so that the .svn and .git directories are not viewable, but the safest method is to NOT publish those directories.
With that said, for optimum security, I’d recommend using the following:
svn export --username user --password password https://org.svn.cvsdude.com/project
svn export command will exclude the .svn directory.
git clone https://email@example.com/project.git
delete recursively .git folder
There are other ways that you can accomplish this in git, for example, git archive. However, git archive does not work with https based remote repositories, and deleting the .git directory is simple and straightforward.
FTP has been around since the 1970s. It is widely used although not secure. However, this is the most basic form of copying files from one location to another.
Pros of using FTP
- Popular, widely used.
- Many free and commercial clients, FileZilla is a good multi-platform client.
- Stable and reliable.
- Many basic hosting and cloud providers ONLY give you FTP access to upload files.
Cons of using FTP
- Not secure because it sends username and password in plain text.
- The actual data sent is not encrypted.
- Not efficient, it goes through each file and folder then uploads them to the FTP server.
If you have SSH access to a hosted or cloud server, then SCP provides a step up from FTP in publishing your content.
Pros of using SCP
- Popular, widely used.
- Many free and commercial clients, PuTTY is a great free, open source client for Windows.
- Secure – username, password, and the content is encrypted via SSH.
Cons of using SCP
- Slightly more complicated setup. For automated publishing and security, you should generate a SSH key pair. This also requires adding the public key to the publishing target.
- Not as efficient compared to rsync over SSH. It will do a straight copy, but unlike rsync over SSH, you are copying all of the files over, where rsync can copy just changed files, which is faster and more efficient.
rsync over SSH
This is one of the most secure, efficient ways to publish your content to any server.
Pros of rsync
- In addition to all of the pros already covered in SCP, rsync checks for differences between files. Only files that are changed are copied over. Therefore, it will be much faster and more efficient.
- Unlike FTP and SCP, you can use rsync to keep an exact mirror of your publishing content. FTP and SCP simply copies file over. However, if you use the
--deleteoption, rsync will delete any files that are not matching what you want to publish.
Cons of rsync
- More complicated to use because there are more options.
- Requires using an SSH key pair.
So far I’ve covered the three basic methods of publishing your code, all of which are available through our one-click deployment tool, Codesion Publisher. Each has its pros, cons, and level of complexity. However, these methods miss one important feature, rollback. In a production environment, you may want to rollback immediately if something went wrong. Re-publishing your code may take longer than you want.
Stay tuned for my next blog post to dig deeper into a couple of advanced methods for publishing with rollback in mind.