5 DevOps practices you should consider starting today

- [] Needs checking
Good morning Shidhin :)


On Tue, Sep 2, 2014 at 3:19 PM, Shidhin <notifications@github.com> wrote:

> In
> source/_posts/2014-07-20-5-devops-practices-you-should-consider-starting-today.markdown:
>
> > +<!-- more -->
> > +
> > +It goes without mentioning, to build a robust architecture you will need to follow the industry standards for example, use a distributed version control system - [git](http://git-scm.com/) is a great one, use automated deployment tools - you should check [Capistrano](http://capistranorb.com/), write automated tests using framework like [PHPUnit](http://phpunit.de/), have some form of continuous integration - you can run automated tests with [Travis CI](https://travis-ci.com/) on different versions of a language and have some internal documentation in place which includes basic to advanced things about the codebase and the systems used. Following similar rules, at [Namshi](http://www.namshi.com) we use some [DevOps](http://en.wikipedia.org/wiki/DevOps) practices which are very helpful to us, here are some main ones:
> > +
> > +
> > +## Virtual Development Environment -Vagrant
> > +
> > +[Vagrant](http://www.vagrantup.com/) is a virtual development environment that works as controller to a virtual machine on your main machine. The virtual machine has all needed software stack installed, each software is installed as a config. It creates a reproducible and portable development machine which is shared among all the developers, that in turn eliminates "Works on my machine" syndrome and also help to get started with working on the codebase in a matter of hours compared to a day.
> > +
> > +With use of vagrant, it is very easy to install new software and update them. You just add some scripts to how the vagrant box is configured and push the changes. All the software engineers will pull it, reload the vagrant machine and done. All of them have the new software and the correct version of it. As the configs, services and even file paths are shared everyone is on the same page when discussing about the system. If you are already interested in vagrant don't hesitate to start reading it's [docs](http://docs.vagrantup.com/v2/getting-started/index.html
> ).
> > +
> > +
> > +## Atomic Deployments
> > +Some months back we used to follow a revised version of [gitflow](http://nvie.com/posts/a-successful-git-branching-model/) and grouped multiple tickets in same deployment, basically some completed tickets (generally 4-8) where merged to the `develop` branch and then merged to the  `release` branch. A tag was created from the `release` branch say `1.2.3` and it was deployed to `staging` then `production` after tests were ok. If all goes well the tag is merged to `master`. Issues with this was, if we had a problem after the deployment pinpointing which ticket introduced this issue was difficult.
> > +
> > +Lets fast forward to now, currently we do **atomic deployments**, it means only one ticket is deployed at a time. Each ticket has it's sole deployment. First the ticket is deployed to `staging` tested and if everything is fine then it's deployed to production.
>
> its instead of it's ( only the first one in this paragraph )
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/namshi/namshi.github.com/pull/11/files#r16981365>.
>