By now, the base structure for the deployment of application has been created. Now we will move on to actual deployment process. First, we will change some settings and then deploy our app.

Deploy.rb

At this stage, our deploy.rb file should appear like this

set :application, "domain.com"
set :user, "username"
set :repository,  "svn+MyTestProject1ssh://12.34.56.789/home/username/repository/MyTestProject1"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
# set :deploy_to, "/var/www/#{application}"

set :port, 30000

set :deploy_to, "/home/demoDir/public_html/#{application}"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
# set :scm, :subversion

role :app, application
role :web, application
role :db, application , :primary => true

Now we will look into the deployment process and define what is needed for the deployment.

Subversion

Subversion should already be installed and configured on the local machine. Working on a default deployment, Capistrano executes commands on the Droplet and looks for the latest version from repository. However, in our scenario, the droplet has not been setup to access the repository. This is because, if we setup the droplet to access repository then we will be required to place private key on the droplet for accessing it without a password. This can lead to security issues, and therefore we have allowed the workstation to access the repository.

This means our workflow will be as follows

1. The latest version is checked from the remote repository
2. Then it is compressed
3. Next, SSH sends it further to the Droplet
4. Finally uncompressing occurs

Although it takes few more seconds in deployment, this gives us an increased level of security.

We can easily setup Capistrano to use this deployment strategy by adding the following line to the deploy.rb file

 set :deploy_via, :copy

Mongrel user

Now we will set up the user who will start mongrel instances. If we don’t do this, the script will fail. We will use the same user that we defined previously.

set :runner, user

deploy.rb

Since we have made a few changes to the deploy.rb file, it should look like this:

set :application, "domain.com"
set :user, "demo"
set :repository,  "svn+MyTestProject1ssh://12.34.56.789/home/usernamer/repository/MyTestProject1"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
# set :deploy_to, "/var/www/#{application}"

set :port, 30000

set :deploy_to, "/home/username/public_html/#{application}"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
# set :scm, :subversion

role :app, application
role :web, application
role :db, application , :primary => true

set :deploy_via, :copy

set :runner, user

Initial Phase of Deployment

Up to now, everything has been done to deploy the app. However, there is one thing is left and that is to let it know how mongrel will start up upon initial deployment. This can be accomplished by using a file called spin located in the scripts folder. We will now create it on the workstation.

 touch script/spin

This file will contain the commands that will be used by Capistrano for controlling mongrels

Now we will set its property in subversion to ensure that it has the correct permissions and can be executed successfully.

 svn propset svn:executable on script/spin

For now, we will place only one line in the file that relates to the usage of mongrel.

/home/username/public_html/domain.com/current/script/process/spawner -p 8000 -i 2 -e production

Commit:

We will run the following command to check which files need to be added to the subversion and will, subsequently, add them.

 svn status

The spin file can also be added

 svn add script/spin

Finally, we will commit the changes to subversion repository.

svn commit -m "added script/spin"

By now, we have reached the stage when we need we deploy and serve the application. In order to make the domain available on the main we have to set up a vhost, which will work specifically for the application that needs to be deployed.

First Deployment

The following command will deploy the app for the first time

cap deploy:cold

You will see a lot of information scrolling in the terminal. Once everything is completed, we can see that Capistrano did everything we expected:

1. Capistrano checked the latest code from subversion
2. It compressed the code into a temp file
3. The code was uploaded
4. The code was uncompressed
5. Then, it copied the code and created symlinks etc
6. Finally, it started two mongrel instances defined in the spin file

Summary:

The process of configuring a virtual host for the app may seem a bit frustrating. By default, Capistrano is not meant to install and configure web servers. Rather, it allows us to take an existing setup and use it to deploy and serve our app by using a simple command.