Как улучшить процесс разработки/тестирования/деплоя?
Все доброго дня!
Подскажите, пожалуйста, как улучшить процесс разработки/тестирования/деплоя?
Небольшой веб проект на yii2+mysql, код в bitbacket (включены smart commits), задачи в jira cloud (kanban: backlog->todo->in progress->review->done), виртуалки в Digital Ocean.
Сейчас разработка и деплой такие:
1. единственная ветка master, изменения базы через миграции.
2. после того как разработчики протестировали фичу у себя на компах, пушат ее в master. Передвигают задачу в Jira: in progress->review
3. master через вебхук, скриптом автоматически деплоится в тестовое окружение
4. выполняется ручное тестирование в тестовом окружении.
5. если багов нет, то выполняется ручной деплой (bash скрипт: git clone, composer, yii migrate, php init, rsync .. etc) на продакшн.
Хочется поменять процесс и на базе TeamCity добавить авто-тесты и некоторую автоматизацию чтобы было так (feature-ветки думал не использовать, так как у нас много небольших правок, а ветки добавляют оверхед):
В идеале, привязать все к задачам в jira и оперировать ими, а не коммитами.
1. две ветки: dev и master (который должен быть всегда готов к деплою на продакшн). Напрямую в master разработчики пушить не должны.
2. после того как разработчики протестировали фичу у себя, пушат ее в dev
3. teamcity слушает ветку dev и после пуша запускает автотесты
4. в случае успешного прохождения тестов приходит уведомление тестеру о необходимости ручного тестирования. В случае неуспешного - email разработчику об ошибке.
5. тестер выполняет ручное тестирование в тестовом окружении.
6. тестер "что-то нажимает" в teamcity и данный коммит (или группа коммитов по одной jira-задаче?) мерджится в master.
7. выполняется ручной деплой (bash скрипт) из master на продакшн. В перспективе деплой меняется на автоматический, так же через teamcity.
Вопросы:
- нормальная ли схема в целом? видите ли вы потенциальные проблемы?
- как реализовать пункт 6 в teamcity?
Попробуйте завести ветку stage, куда будет выполняться периодический мердж (например, 2 раза в день) из dev-ветки. Можно на тимсити завести отдельно подпроект для этого, с шагами:
- найти последнюю успешную сбоку dev-ветки
- влить ее в stage
- уведомить тестировщика
Тестировщик получает уведомление, выполняет ручное тестирование. Все круто - вливаем в master
AstonMartin, да, верно. В идеале "живой" тестировщик должен проверять только ту логику проекта, которая а) слишком трудозатратна, чтобы ее формализовать в виде теста(-ов) и б) по объективным причинам должна быть протестирована вручную
Все остальное - обкладывайте тестами. Конечно, важно найти золотую середину (чтобы время на написание тестов не превышало 30% от времени написания кода ) - как правило, в тесты уходит все фичи, указанные в ТЗ + найденные в ходе разработки баги. Насчет 30% времени - это примерно) Если изначально проект стартует в рамках TDD, то там все 70% будут )
"Хочется поменять процесс и на базе TeamCity добавить авто-тесты и некоторую автоматизацию чтобы было так (feature-ветки думал не использовать, так как у нас много небольших правок, а ветки добавляют оверхед):"
В том-то и дело, что авто-тесты без фича веток не очень хорошо будут работать.
Подробнее:
Автотесты обычно должны триггериться на коммит. Но это также означает, что разработчик не тестирует у себя локально приложение, а просто коммитит и ждет ответа от автотеста.
А если он будет коммитить в мастер - то один разработчик может сломать билд для всех.
Если использовать отдельную ветку для автотеста, опять же в нее может закоммитить несколько разработчиков и будет неясно кто кому что сломал.
Поэтому и используется фичабренчи - каждый разработчик создал себе фичабренч типа feature/lalala, и автотест реагирует на коммит в любой бренч по маске feature/*
Если тест успешен - тогда можно мержить в мастер - обычно для этого используется какой-то промежуточный инструмент перед гитом - gitlab, gerrit, bitbucket, где удобно настроить создание pull request-ов так, чтобы они не позволяли мержить, пока нет 1 ревью и 1 успешного билда.
Да, в этом есть логика.
Но у нас пока очень маленькая команда, пуши редки и поэтому не часто случается, что разработчики одновременно зальют каждый какое-то существенное изменение.
Фича бранчи меня немнго напрягают тем, что под них же, под каждый, по идее, надо автоматически разворачивать тестовое окружение. Пока не понятно как это все делать.
Мы тоже думали про TeamCity, но, после того, как освоили Bitbucket pipelines, как-то решили обходиться без него.
Там можно настроить автоматический (то есть после пуша в ветку, любую) или ручной деплой (у нас деплоится на хероку).
То есть ваш пункт 6, я так понимаю, это наш ручной деплой - делается действительно практически одним нажатием.
Простой
