devxlogo

Automating Web Site Deployment

Automating Web Site Deployment

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.1Host: localhost:4567X-Github-Delivery: 72d3162e-cc78-11e3-81ab-4c9367dc0958User-Agent: GitHub-Hookshot/044aaddContent-Type: application/jsonContent-Length: 6615X-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:

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/bashfor 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/Capfileproject/config/deploy.rbproject/config/deploy/staging.rbproject/config/deploy/production.rbproject/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 nameset :application, "mywebsite"# Set user which Capistrano will run commands withset :user, "deployer"# Set deployment pathset :deploy_to, "/home/#{user}/sites/#{application}"set :use_sudo, false# Configure git remote repository location and desired branchset :scm, "git"set :repository, "[email protected]: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 branchset :scm, "git"set :repository, "[email protected]: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.

devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist