CustomScripts Blog

I recently needed to deploy a Symfony application to a production server.

After some searching, I noticed Capifony.
Capifony is an extension of Capistrano, specifically built for Symfony projects.

For those who don’t know Capistrano, it is a deployment utility build in ruby, more specifically for ruby projects, but you get a few extensions that you can use to deploy PHP applications as well.
Here is an excerpt about Capistrano: “Capistrano is a utility and framework for executing commands in parallel on multiple remote machines, via SSH….Capistrano is a utility and framework for executing commands in parallel on multiple remote machines, via SSH”

So the first part of setting up Capifony is to create an SSH connection to the production server. For that I created a public ssh key without a password that I just copied over to the server, so this allows me to connect to the production server from my local machine without having to worry about entering a password every time, and this also makes it easier for Capifony to connect to the server to deploy the application.

On the production server, I needed to make sure that it can connect to my private Github account, which is also accomplished using SSH, so that the latest code can be cloned to the machine.
The last step was just to create the deployment configuration, which look like the following:

set :application, "Application Name"
set :domain,      "domain_name"
set :deploy_to,   "/var/www/html"
set :app_path,    "app"
set :deploy_via, :remote_cache
set :repository,  "github-repository"
set :scm,         :git
# Or: `accurev`, `bzr`, `cvs`, `darcs`, `subversion`, `mercurial`, `perforce`, or `none`
set :model_manager, "doctrine"
# Or: `propel`
role :web,        domain                         # Your HTTP server, Apache/etc
role :app,        domain                         # This may be the same as your `Web` server
role :db,         domain, :primary => true       # This is where Symfony2 migrations will run
set  :keep_releases,  3
set :shared_files,      ["app/config/parameters.yml", "app/environment.txt"]
#set :shared_children,     [app_path + "/logs", web_path + "/uploads", "vendor"]
set :shared_children,     [web_path + "/uploads", "vendor"]
set :use_composer, true
set :update_vendors, true
set :update_assets_version, true
set :dump_assetic_assets, true
set :interactive_mode, false
set :writable_dirs,     ["app/cache", "app/logs"]
set :webserver_user,    "apache"
set :permission_method, :acl
set :interactive_mode, false
set :use_sudo, false
set :user, "root"
default_run_options[:pty] = true
# Be more verbose by uncommenting the following line
logger.level = Logger::MAX_LEVEL
# Custom Tasks
after "symfony:cache:warmup", "deploy:set_permissions" # sets the required folders to writable
after "deploy:set_permissions", "permission:setowner" # Change ACL on the app/logs and app/cache directories
# Sets the directory to the correct owner
namespace :permission do
  task :setowner do
      capifony_pretty_print "--> Change folder to owner #{webserver_user}"
      run "chown -R #{webserver_user}: #{latest_release}/"
      puts_ok
  end
end

And that’s it. So each time I need to update changes, I just use the command

cap deploy

, then all the latest code is pushed to the server.
Capifony also keeps a history of the previous 5 releases, so if something went wrong on deployment, I can just roll back to the previous version.

I posted a (long) while ago about a billing application that I wanted to create. This application is still in the works, in fact it got some new life breathed into it some weeks back.
On my original post, I mentioned that I wanted to use Zend Framework. Those plans also changed quite a lot. The application was actually built some couple of years ago, when I was still heavy into CakePHP. I actually had it at a workable (but unstable) state at that time. But I wasn’t happy with the code base, and it didn’t feel flexible enough for me.
So that’s why I decided to rewrite it using Zend Framework, so I can make it a bit more flexible and robust.
Truth be told, I didn’t get very far. I was so busy creating my own framework on top of Zend’s MVC structure (because I felt it lacked some functionality and still needed some work to get it to a proper working state), that I didn’t actually get to a point that I started adding functionality to the application. All the changes was just core changes to get the structure working, without any functionality of the actual application. So after some time I started working with another framework…

Behold Symfony2

If you read my post about why I switched from CakePHP to Symfony2 (and you definately must read it if you haven’t), then it would come as no surprise that I decided to start from scratch (again), this time using the most-awesome Symfony2 framework.
This time round, I got a bit clearer vision of what I want to accomplish with the application, and the bit of coding I have done so far already feels a lot more stable, flexible and usable than any of the previous code I did with other frameworks. At this point it actually feels like the application is going somewhere very fast, and I feel much more confident in what I’m trying to accomplish. So you are probably wondering by now…

Why use a framework?

Again, if you haven’t read my previous post about the switch from CakePHP to Symfony2, then you definitely must go read it.
So why am I using a framework to build the application, instead of doing everything from scratch like most high-profile open-source apps available?
Well, there are more reasons than what I am willing to share at this moment, but let me highlight some of the most important:

Community:
The Symfony framework (as well as many other frameworks) already have a large community helping out, filing bug reports, creating patches etc.
Just by using the framework, I already have access to hundreds of community members that might be willing to lend a hand where necessary, especially because I’m releasing the application as open-source.

Features:
Why worry about features such as security, acl, databse abstraction, plugins/extensions etc. if the framework already handles all of it. Using a framework like Symfony2 allows me to spend more time actually building the application, instead of having to worry about standard features every web application need.

Flexibility:
As with (almost) every framework, there is the ability to add extension/plugins. With Symfony2, you get different bundles that you can just plug in and most of the time it just works. And with Drupal and ez Publish using Symfony2, how awesome would it be to just add the billing bundle to your CMS, or any existing Symfony2 application? So instead of having to write plugins/extensions for the specific framework of the application, almost any Symfony2 bundle can fit right in.

Why Open Source

It’s always nice to search for some specific application you want, and see a free version of what you want. Not a lot of people want to buy software, or can afford it, especially with start-ups that have a very limited budget. I’ve used a lot of open-source applications, and each time I’m searching for something new, I always hope to find something that is free. So this is my way of giving back to the open-source community.

Source

So if you would like to have a look at the source, maybe contribute, give ideas etc, you can visit the repository at Github.
The features for now is still very simple, invoicing, quotes, client management, project management (planned for the far future) as the application is still barely an infant. But as it progresses, The feature list will be a bit more clear, it will have it’s own dedicated website, updated wiki’s, developer doc etc. So be sure to keep an eye on the repository and this blog for updates, and please feel free to join the project and help out in any way you can.