project deploy (project deployment)

Question

git

We are looking for the optimal and most hemorrhoid-free solution for the next. tasks:

- I want to have an “easy” (especially in terms of traffic) way to deploy an application to production, with the same easy possibility of “switching” (rollback) to working versions.

now the developers are working each in their own sendbox, there is a central dev server. Where everything that is done is debugged. after everything is tested and fixed, you need to apply all changes in production.

GIT is used as SLE.

On the dev server, there are two branches master and dev.
From the latter, clones (pools) are made; all pushes fall into it.
According to the hook, all its contents are copied to the vvv_root of the virtual host.

after tests and fixes, everything is merged into the master and again deployed to the local Wirth. host for final testing.

As soon as everything is ready, I want to throw everything into production.

- I want to NOT flood the entire tree every time (the project is large)
- and I want to be able to quickly and easily roll back a step or more back in case of suddenly found bugs.

To do as it was done with SVN (via svn up) does not seem to be entirely ideologically correct.

any ideas?

PS Previously, everything worked through SVN, and therefore there are .svn folders in production (closed via shttp), I want to find a way that by switching to it, not to remember the old days :)

Answer 1

Well, what's stopping you from deploying the same Git repository to production and receiving only changes to it?

Answer 2

I recommend Capistrano (http://habrahabr.ru/tag/capistrano/):
- we use it together with the multistage module, it allows you to deploy the code to several stage servers (using the “cap demo deploy” command, the testing branch is laid out on the demo server, “cap production deploy” - the master branch on the production branch)
- allows you to do cached-copy: at the first deployment, a folder with a clone of the repository is created, at subsequent deployments, git pull is done in it. Further, this folder is stupidly copied to the target folder along with .git (our www-root is not in the root of the project, but in one of the subfolders - so paranoia does not torment us much)
- deploy: rollback - rollback to the previous deployment
- it is possible to set all sorts of different tasks: before update, after update, restart, web: disable (server blocking for the update period)
- we also found and finished the module for creating tags with each deployment - now right in the commit tree you can easily determine who, what, where and when deployed. Differences between versions? You are welcome. Release date? You are welcome. Sweetie turned out :)
- deploying to 10 servers at once and executing all sorts of different commands locally / remotely - for granted

Answer 3

Jenkins aka Hudson?