Last Updated Aug 23, 2010 — Enterprise Agile Planning expert
Enterprise Agile Planning


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

Whether you are using SVN or Git, there are some steps you need to be aware of before you copy your code to a production or test environment.

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

svn export command will exclude the .svn directory.


git clone https://[email protected]/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

  1. Popular, widely used.
  2. Many free and commercial clients, FileZilla is a good multi-platform client.
  3. Stable and reliable.
  4. Many basic hosting and cloud providers ONLY give you FTP access to upload files.

Cons of using FTP

  1. Not secure because it sends username and password in plain text.
  2. The actual data sent is not encrypted.
  3. 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

  1. Popular, widely used.
  2. Many free and commercial clients, PuTTY is a great free, open source client for Windows.
  3. Secure – username, password, and the content is encrypted via SSH.

Cons of using SCP

  1. 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.
  2. 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

  1. 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.
  2. 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 --delete option, rsync will delete any files that are not matching what you want to publish.

Cons of rsync

  1. More complicated to use because there are more options.
  2. 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.


Are you ready to scale your enterprise?