Данный пост противопоказан и может оскорблять чувства верующих в церковь Мартина Фаулера, так как является довольно вольной трактовкой, но обтесанной годами моей практики.

Сидит программист, пишет свой код, думает о пиве и здесь появляется другой программист, с ним тестировщик и, прости Господи, проектный менеджер. Здесь уже не до пива, код больше нельзя править на сервере через удалённый доступ. Приходится разворачивать git, лепить ветки, создавать билды и гонять тесты и в дело вступает супергерой Continuous. Последнее время принято мешать три шага Continuous в одну кучу, хотя эти шаги сильно отличаются по целям и подходам. Эти шаги — Continuous Integration, Continuous Delivery и Continuous Deployment.

Continuous Integration — интеграция вашего кода c общим репозиторием. После того как вы совершаете коммит-пуш, система видит его, делает билд, запускает unit тесты и собирает разную статистику о качестве, покрытии и метрики кода. После этого в интерфейсе системы мы может просмотреть всё собранное. В качестве сервера CI можно использовать прожёрливый но удобный Jenkins (Java) или провославный, но сырой PHPCI (PHP). Очень часто грешат тем, что не контролируют эти самые метрики, доверяя только code review. Например, phpmetrics не только всё считает, но и рисует графики, где визуально можно заметить проблемы на проекте. Из-за того, что мы гоняем только unit тесты, то билд получается простой, все происходит почти мгновенно, можно делать даже на машине разработчика, а уже по итогам делать пуш на сервер. Так что программист может и должен коммитить сколько угодно раз на день.

Continuous Delivery — непрерывная доставка. Развёртывание проекта на веб сервере, чтобы его могли посмотреть тестировщики, погонять функциональные, интеграционные, нагрузочные и прочие тесты. Этот билд является довольно тяжёлым и долгим, нам нужна полноценная и заполненная фикстурами база данных, нужны дополнительные ассеты, вроде картинок товаров или видео для скачивания. Потому данный шаг не так часто делается, а только после CI, иногда только по ночам, а бывает даже запускается не в автоматическом режиме.

Continuous deployment — деплоймент на боевые сервера. Важным отличием от предыдущего шага является понимание того, что билд может не пройти или результат на реальных данных будет неверный, потому нужно быть готовым к откату. Здесь на помощь приходят утилиты вроде capistrano (Ruby) или rocketeer (PHP). Они создают разворачивают каждый релиз в отдельной директории, переключая текущий, который по сути является ссылкой на один из релизов.

Rocketeer штука очень полезная и годиться для первых двух этапов, особенно, если вы не используете фиче бранчи и валите все правки в один stage-prelive. Тогда в случае проваленных тестов он сделает revert для последних правок и rollback для релиза. Помимо этого его можно использовать как task runner, как и наоборот — с помощью task runner можно делать deploy. Так как последнее время у некоторых разработчиков проблемы с поиском php based утилит, то посоветую Robo, не вкручивайте, пожалуйста, всякие gulp или elixir.

Вроде ничего не забыл, шаги очень простые и настроив один раз вы сможете внедрять всю цепочку в новые проекты менее чем за день без специально обученных людей. В интернете можно найти сервисы, где все уже работает, но я не советую ими пользоваться, нужно хотя бы раз самому разобраться, да и дополнительная гибкость рано или поздно вам понадобится.