Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Automating Web Site Deployment

Examine a few of the approaches and tools that can help standardize and automate Web site deployment to a certain level.


advertisement

Automating Web site deployment is an important topic for both individuals and companies that provide Web development and maintenance services. Although it is often seen as a final small task at the end of the project, it can save a lot of time and increase productivity if handled the right way. In this article, we will examine the approaches and tools that can standardize and automate Web site deployment to a certain level.

FTP-based Deployment

Deployment via FTP is commonly used by freelancers and in cases where the Web site is deployed to a shared hosting server. These servers usually don't have git installed (and lack permissions to install libraries manually), meaning that some of the more advanced tools cannot be used (see Capistrano below).

Fortunately, a certain level of automation can be achieved by using git cloud hosting services, such as Beanstalk. They offer an automatic deployment feature that connects to your Web site via FTP and copies the files from your git server to your hosting server.



Advantages: Can be used on shared hosting, does not require additional software on the server, easy to configure

Disadvantages: Small automation, slow, dependent on third-party service

Git Auto-Sync

Some git hosting services, such as GitHub, support Webhooks. In other words, it can be configured that, every time an event happens on the repository, it sends an HTTP POST request with payload to the specified URL.

On GitHub, Webhooks settings can be found by going to your repository's settings and then clicking on Webhooks on the left hand side. Once you have created a Webhook, GitHub will send something similar to the following after each push to the repository:

POST /deploy.php HTTP/1.1

Host: localhost:4567
X-Github-Delivery: 72d3162e-cc78-11e3-81ab-4c9367dc0958
User-Agent: GitHub-Hookshot/044aadd
Content-Type: application/json
Content-Length: 6615
X-GitHub-Event: issues

{
  "action": "opened",
  "issue": {
    "url": "https://api.github.com/repos/octocat/Hello-World/issues/1347",
    "number": 1347,
    ...
  },
  "repository" : {
    "id": 1296269,
    "full_name": "octocat/Hello-World",
    "owner": {
      "login": "octocat",
      "id": 1,
      ...
    },
    ...
  },
  "sender": {
    "login": "octocat",
    "id": 1,
    ...
  }
}

Now, the deploy.php would handle syncing with git by executing shell commands:

<?php

// This script assumes two environments - staging and production
// There are two git branches - dev (staging) and master (production)
// The repositories have already been cloned to their respective directories

$path         = "/var/www";
$path_staging = "/var/www/staging";
$path_prod = "/var/www/production";

echo shell_exec("cd {$path_staging} && git checkout dev && git pull && cd {$path_prod} && git checkout master && git pull");

Pay attention to the permissions — deploy.php script must have the permission to execute shell commands and to write to files. Also, secure the script, so that you are sure that the request comes from GitHub and not some other source.

Advantages: No need to manually sync with git, it can sync only a specific branch

Disadvantages: Too closely tied to git push events, cannot perform deployment tasks unrelated to git

Bash Scripts

Deployment via bash scripts is similar to git, but offers more control in terms of deployment time and running non-git tasks. It is also a better, and easier, solution security-wise, as the script will be located outside of the Web root and run by a system user.

While bash scripting is too broad a topic to be covered in this tutorial, here is an example bash script that synchronizes all Web sites on the server with their corresponding git repository:

#!/bin/bash
for repo in /home/myusername/sites/*/; do
	(cd "${repo}" && git pull)
done

Advantages: More control, very flexible

Disadvantages: Requires bash scripting knowledge, lack of standardization

Capistrano

Capistrano is a server automation and deployment tool. Although it is written in Ruby, it can be used to deploy projects of any language or framework, such as PHP or Java.

Basically, Capistrano connects to the server(s) through SSH and executes the steps needed to deploy the project. These steps can either be configured manually (by writing Rake tasks yourself) or imported as a part of pre-build task libraries.

Before you start using Capistrano, make sure that you have Ruby 2.0 installed on your local machine, version control (Git, Mercurial or SVN both on local machine and the server) and Bundler. Then, add the following to your project's Gemfile:

group :development do
  gem "capistrano", "~> 3.6"
end

Finally, run the installation:

bundle install

At this point, Capistrano has been installed. Let's create the necessary configuration files and directory structure:

bundle exec cap install

The following file structure is created:

project/Capfile
project/config/deploy.rb
project/config/deploy/staging.rb
project/config/deploy/production.rb
project/lib/capistrano/tasks

By default, Capistrano creates configuration files for two environments — staging and production. While the default deployment configuration is located in deploy.rb, it can be overridden for each environment in staging.rb and production.rb .

If you would like to have different environments, specify them when running cap install:

bundle exec cap install STAGES=staging,uat,production

Now, let's create a sample deployment configuration:

# deploy.rb content:
require "bundler/capistrano"

server "myserver.com", :web, :app, :db, primary: true

# Application name
set :application, "mywebsite"

# Set user which Capistrano will run commands with
set :user, "deployer"

# Set deployment path
set :deploy_to, "/home/#{user}/sites/#{application}"
set :use_sudo, false

# Configure git remote repository location and desired branch
set :scm, "git"
set :repository, "git@github.com:johndoe/#{application}.git"
set :branch, "master"

We can create a slightly different configuration for staging environment by editing staging.rb :

# staging.rb content:
server "staging.myserver.com", :web, :app, :db, primary: true

# Configure git remote repository location and desired branch
set :scm, "git"
set :repository, "git@github.com:johndoe/#{application}.git"
set :branch, "dev"

To do the deploy, run:

cap deploy

To deploy only a particular environment:

cap production deploy

This is just a basic example. To see what else Capistrano can do, check the documentation.

Advantages: Highly customizable, high level of automation

Disadvantages: Takes some time to learn the configuration syntax and options

Conclusion

FTP-based deployment and git auto-sync should be regarded as "fallback" options and tools like Capistrano should be used instead. These tools take some time to configure, but can increase productivity later, especially when managing a large number of Web sites.



   
Vojislav is a web developer, designer and entrepreneur, based in Belgrade, Serbia. He has been working as a freelancer for more than 6 years, having completed more than 50 projects for clients from all over the worlds, specializing in designing and developing personal portfolios and e-commerce websites using Laravel PHP framework and WordPress content management system. Right now, he works as a full-time senior web developer in a company from Copenhagen.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date