Комментарии 11
У меня процесс реализован по-другому.
1. Есть development build, который следит за коммитами и выполняет «лёгкие» задачи — статический анализ кода, юнит-тесты с моками, рассылает уведомления о упавшем билде, собирает статистику и строит красивые графики. Никакого deployment здесь не происходит.
2. Есть qa build, который запускает qa (извините за тафтологию). Тут уже прогоняются все тесты, юниттесты и selenium, и в случае успеха, происходит deploy проекта и создание тега в SVN.
3. Есть release build. Для его запуска из dropdown можно выбрать тег для релиза и этот билд только произведёт deploy релиза проекта.
1. Есть development build, который следит за коммитами и выполняет «лёгкие» задачи — статический анализ кода, юнит-тесты с моками, рассылает уведомления о упавшем билде, собирает статистику и строит красивые графики. Никакого deployment здесь не происходит.
2. Есть qa build, который запускает qa (извините за тафтологию). Тут уже прогоняются все тесты, юниттесты и selenium, и в случае успеха, происходит deploy проекта и создание тега в SVN.
3. Есть release build. Для его запуска из dropdown можно выбрать тег для релиза и этот билд только произведёт deploy релиза проекта.
«Шикарная» статья. Берем хрень — тут все просто. Еще одну хрень — тоже все просто. Еще одну — все конечно просто. Складываем хрени вместе — тут все элементарно… Зачем это все писалось крогме очевидного — крикнуть громко на весь хабр «Я крут, я CI для php проектов юзаю» — непонятно.
Почему у вас в заголовке (и тегах) написано Continuous Delivery, а в статье упоминается только Continuous Integration? В чем отличия?
Continuous Delivery — конвеер доставки приложения в конечную точку, состоящий из нескольких шагов: сборка проекта, выпуск релиза, тестирование командой QA, деплой на сервера. Шаги могут варьироваться.
Continuous Integration — один из шагов, который выполняет регулярные сборки в целях мониторинга состояния приложения на стадии разработки.
Continuous Integration — один из шагов, который выполняет регулярные сборки в целях мониторинга состояния приложения на стадии разработки.
Я сначала тоже тэги использовал (у меня гит на проекте), но потом перешел на создание брэнчей для того, чтоб вносить изменения именно в тот код, который на прод пошел.
можно почитать как это делают в etsy
codeascraft.etsy.com/2010/05/20/quantum-of-deployment/
еще в github выгружают очень часто, кажется у Zack Holman
codeascraft.etsy.com/2010/05/20/quantum-of-deployment/
еще в github выгружают очень часто, кажется у Zack Holman
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Continuous Delivery PHP приложений