Комментарии 21
Фундаментальный вопрос: как вы делаете хотфиксы?
Ну и по мелочи:
>> Когда наш трудолюбивый программист решил, что закончил задачу, ему достаточно просто перевести в багтрекере ее статус в testing и приступить к следующей.
>> После смены статуса тестировщик получает извещение о том что эту задачу можно проверять.
>> Первым делом он должен проверить статус тестов с последнего комита, и в случае неудачи сразу вернуть таск автору.
А почему проверка статуса тестов не делается автоматически с откатом задачи обратно разработчику?
У нас, например, хотя так далеко все и не зашло, зато код, не проходящий быстрые тесты, нельзя даже зачекинить (в вашей терминологии — смержить в серверную ветку).
Ну и по мелочи:
>> Когда наш трудолюбивый программист решил, что закончил задачу, ему достаточно просто перевести в багтрекере ее статус в testing и приступить к следующей.
>> После смены статуса тестировщик получает извещение о том что эту задачу можно проверять.
>> Первым делом он должен проверить статус тестов с последнего комита, и в случае неудачи сразу вернуть таск автору.
А почему проверка статуса тестов не делается автоматически с откатом задачи обратно разработчику?
У нас, например, хотя так далеко все и не зашло, зато код, не проходящий быстрые тесты, нельзя даже зачекинить (в вашей терминологии — смержить в серверную ветку).
Конечно любые правила не без исключений. Совсем в критичных ситуациях таск мержится в master минуя staging. После чего master сразу мержится в staging, про прогона тестов и для актуализации ветки. Такие случаи бывали, но в большинстве случаев мы все же решаем делать откат релиза и в течении спринта без аврала фиксим. Спринты у нас короткие всего 1 неделя, поэтому обновляем небольшими порциями и фиксы приходят быстро.
По поводу возврата задачи, у нас тоже такая идея была, но просто рук не хватило пока реализовать. Но я думаю скоро тоже сделаем и я добавлю это в статью.
А в Вашем случае, я так понимаю запрет сделан на прекомит хуках?
По поводу возврата задачи, у нас тоже такая идея была, но просто рук не хватило пока реализовать. Но я думаю скоро тоже сделаем и я добавлю это в статью.
А в Вашем случае, я так понимаю запрет сделан на прекомит хуках?
>> Совсем в критичных ситуациях таск мержится в master минуя staging.
«и CI, без каких-либо тестов, деплоит проект в продакшен. „
… не делайте так.
>> Спринты у нас короткие всего 1 неделя, поэтому обновляем небольшими порциями и фиксы приходят быстро.
У нас тоже итерации в неделю, но за неделю бывает до десятка хотфиксов.
>> А в Вашем случае, я так понимаю запрет сделан на прекомит хуках?
В нашем случае запрет сделан на TFS Gated Checkins.
«и CI, без каких-либо тестов, деплоит проект в продакшен. „
… не делайте так.
>> Спринты у нас короткие всего 1 неделя, поэтому обновляем небольшими порциями и фиксы приходят быстро.
У нас тоже итерации в неделю, но за неделю бывает до десятка хотфиксов.
>> А в Вашем случае, я так понимаю запрет сделан на прекомит хуках?
В нашем случае запрет сделан на TFS Gated Checkins.
Критичными ситуациями я называю те в которых нет времени на долгие тесты. Быстрые тесты в любом случае пройдут, а долгие пойдут параллельно с деплоем при мерже ветки master в staging.
Если проблема не критичная, но и до конца спринта ждать не может, то фикс проходит через staging и деплоится вместе с тем что уже накопилось за часть спринта.
Если проблема не критичная, но и до конца спринта ждать не может, то фикс проходит через staging и деплоится вместе с тем что уже накопилось за часть спринта.
>> фикс проходит через staging и деплоится вместе с тем что уже накопилось за часть спринта.
Это уже не хотфикс — у вас может быть так, что в стейджинге есть проблемы, не связанные с фиксом, и они блокируют его выкатку.
Это уже не хотфикс — у вас может быть так, что в стейджинге есть проблемы, не связанные с фиксом, и они блокируют его выкатку.
если с таском есть проблемы то он откатывается из staging и доделывается в своей ветке. при необходимости staging можно смержить в ветку таска для воспроизведения проблемы.
Линейность нарушается. Всего этого можно было бы избежать, имея тесты на мастере.
Суть в том что надо рассматривать staging именно как будущий master и вести его так что бы его в любой необходимый момент можно было выкатить. Если на master'е проводить тесты, то они будут полностью дублировать тесты со staging'а. Это может очень сильно увеличить время деплоя. В нашем случае master служит только как метка для понимания того что сейчас на продакшене. Таким образом важной веткой за которой действительно надо следить становится staging.
Еще вопрос — как вы делаете откаты ошибочного функционала?
У каждого в команде не больше 2-х рабочих инструментов
Это вообще что за метрика такая, и чем наличие трех или четырёх инструментов хуже? Представьте себе специалиста вообще любой профессии, хвастающегося тем, что он работает всего двумя инструментами.
А представьте себе разработчика, которому надо помимо написания кода, написать о том что сделал в таске, запустить тесты, написать тестировщику что можно проверять, самому задеплоить, зайти еще на какой-нибудь сервис поставить там галочку, зайти еще в одно место чтобы указать время затраченное на задачу и т.д. В некоторых случаях список можно продолжать и продолжать. Чем больше используется инструментов, тем больше разработчику приходится отвлекаться от работы, тем чаще подстраиваться под разные интерфейсы, и как пример, тем дольше вводить в курс дела нового сотрудника.
Не просто так большинство сервисов стремятся к принципу «все в одном».
Не просто так большинство сервисов стремятся к принципу «все в одном».
Git flow.
Есть ли смысл рассказывать об удобствах?
Есть ли смысл рассказывать об удобствах?
CI постоянно мониторит гит репозиторий и по каждому комиту в тасковых ветках запускает процесс выполнения тестов.
А почему бы не сделать наоборот — git вызывает CI и прогонку тестов при выполнении каких-либо условий? В таком случае можно значительно снизить нагрузку на сам CI сервер, как мне кажется.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизируем рабочий процесс