This primer is broken up into major sections below.

Moving Files

If you are like me your web server isn’t the same machine as your development PC at least I hope not! You will need a way to get files to your web servers.

Push: Push deployments are when files are transferred from the client to the server. An example of this would FTP, or many other file transfer protocol. This involves opening up a client, and manually or automatically transferring the files from your PC to another computer. This could also involve transferring them using a network file system. FTP clients are included with most major operating systems.

Pull: Triggering the server to download files from another location. An example of this would be using a third party program to download the files from web or ftp directory. WGet, SVN, or another similar program could be used.

WGet: Gnu WGet is free software for retrieving files over HTTP

FileZilla: Open source FTP client and server.

Source (Revision) Control

Source control is critical for being able to control releases, and code. Source control allows you to version your applications, and download a particular version from your source control repository. There are many flavors of source control. Personally I prefer Subversion (SVN). For information on source control.

SVN: Open source, source control client and server.

CVS: Open Source, been around since the 80’s, Concurrent Versioning System

Mercurial: Open Source, Distributed Version Control in Python.

GIT: Open Source, Distributed Version Control

Bazaar: Open Source, Distributed Version Control

Visual Source Safe: Microsoft’s Legacy Version Control

Team Foundation Server: Microsoft’s Prefered Version Control, as well as project tracking

Automation

When I first started building websites. All my deployments were done manually over FTP, and it sucked! Then I started using a better FTP client, and guess what it still sucked! I dreaded deploying, it was error prone, and I looked like an idiot because I forgot a file here or there. It all changed when I started automating my deployments, and I haven’t looked back since.

Depending on what language, or platform you are developing on or for. It is very likely there is an automation application for you system. There is a large class of open source build automation applications based in some way off ANT for Java, which is java version of MAKE.

ANT and it’s derivatives are build scripts which are programmed using XML. Using the ANT XML files you can control file copying, running builds, unit tests, and a number of other deployment and build related tasks. Most of these applications support building custom tasks in their native language, so if it doesn’t support what you need it is very easy to build on top of these platforms.

Make: GNU Build Tool, best suited for compiling applications, custom file configuration.

Ant: Java Build Tool, best suited for building and deploying Java applications.

NAnt: .NET port of Ant, best suited for building and deploying .NET applications.

Phing: PHing Is Not GNU make, best suited for deploying PHP applications.

Maven: Similar to Ant, but different application, it is network ready, and uses a system know as the Project Object Model.

Rake: Similar to Make for Ruby, and the config files use a Ruby syntax.

Other Techniques and Tools

Divide and Conqueror

Divide applications deployments up into different sections, so it is very easy to pin point major errors. One example of this is dividing a compiled web applications into binary, and non binary changes, and then deploy one after the other.

Differential

Create a deployment of only the files that have changed since the last release. An example would be using source control to download files that have changed, and only deploying those. The advantages are it will reduce time during deployment. It may also have the issue of missing files, or other items.

Putting it all together

These are just some of the building blocks for deployment strategies. Building a consistent deployment structure will depend on the number of production, and QA environments that host an application. Sometimes you may not even have access to the production servers. These techniques, and tools are very flexible to support even the most rigorous of deployment structures.

The deployment process should never be a source of stress, and deployment processes should never be the source of errors. Using a consistent, and stable deployment process will reduce both stress and errors.

Bookmark It