src_deploy.md

Symfony2 example project with:

• Ruby (gem): manage deps (chef, cap)
• Opscode Chef: apply config. to target system
• Berkshelf: manage chfe deps (cookbooks)
• Capistrano: deploy sources to server
• composer: deps manager for php
• Symfony 2
• vagrant

Deployment tools in the source repository:

.
├── Berksfile
├── Berksfile.lock
├── Gemfile
├── Gemfile.lock
├── app/
├── Capfile
├── composer.json
├── composer.lock
├── config/
├── cookbooks/
├── solo.json
├── solo.rb
├── src/
├── vendor/
└── web/

• one big repository
• could lead to heavy processes (you always have to clone everuthing)
• messy VCS history
• can't manage rights properly

With two repositories:

.
├── Berksfile
├── Berksfile.lock
├── Capfile
├── config/
├── cookbooks/
├── Gemfile
├── Gemfile.lock
├── solo.json
└── solo.rb

.
├── app/
├── composer.json
├── composer.lock
├── src/
├── vendor/
└── web/

• 2 clean repositories, 2 distinct histories
• reusability: deployment project could be used on several projects
• deployers do not care of the source code, they only know how to deploy it
• developers do not care how the target systems are set up, they only want the source code

Let's add vagrant so everybody can test:

.
├── Berksfile
├── Berksfile.lock
├── Capfile
├── config/
├── cookbooks/
├── Gemfile
├── Gemfile.lock
├── packer.json
├── solo.json
├── solo.rb
└── Vagrantfile

.
├── app/
├── composer.json
├── composer.lock
├── src/
├── Vagrantfile
├── vendor/
└── web/

• ops can know test their recipes using vagrant on the deployment project
• the can also package base images for prod. and dev. envs
• devs get a pre-installed VM which they can use in seconds