Оптимизируем рабочий процесс

[lair]

Фундаментальный вопрос: как вы делаете хотфиксы?

Ну и по мелочи:

>> Когда наш трудолюбивый программист решил, что закончил задачу, ему достаточно просто перевести в багтрекере ее статус в testing и приступить к следующей.
>> После смены статуса тестировщик получает извещение о том что эту задачу можно проверять.
>> Первым делом он должен проверить статус тестов с последнего комита, и в случае неудачи сразу вернуть таск автору.
А почему проверка статуса тестов не делается автоматически с откатом задачи обратно разработчику?

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

[leninlin]

Конечно любые правила не без исключений. Совсем в критичных ситуациях таск мержится в master минуя staging. После чего master сразу мержится в staging, про прогона тестов и для актуализации ветки. Такие случаи бывали, но в большинстве случаев мы все же решаем делать откат релиза и в течении спринта без аврала фиксим. Спринты у нас короткие всего 1 неделя, поэтому обновляем небольшими порциями и фиксы приходят быстро.

По поводу возврата задачи, у нас тоже такая идея была, но просто рук не хватило пока реализовать. Но я думаю скоро тоже сделаем и я добавлю это в статью.
А в Вашем случае, я так понимаю запрет сделан на прекомит хуках?

[lair]

>> Совсем в критичных ситуациях таск мержится в master минуя staging.
«и CI, без каких-либо тестов, деплоит проект в продакшен. „
… не делайте так.

>> Спринты у нас короткие всего 1 неделя, поэтому обновляем небольшими порциями и фиксы приходят быстро.
У нас тоже итерации в неделю, но за неделю бывает до десятка хотфиксов.

>> А в Вашем случае, я так понимаю запрет сделан на прекомит хуках?
В нашем случае запрет сделан на TFS Gated Checkins.

[leninlin]

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

Если проблема не критичная, но и до конца спринта ждать не может, то фикс проходит через staging и деплоится вместе с тем что уже накопилось за часть спринта.

[lair]

>> фикс проходит через staging и деплоится вместе с тем что уже накопилось за часть спринта.
Это уже не хотфикс — у вас может быть так, что в стейджинге есть проблемы, не связанные с фиксом, и они блокируют его выкатку.

[leninlin]

если с таском есть проблемы то он откатывается из staging и доделывается в своей ветке. при необходимости staging можно смержить в ветку таска для воспроизведения проблемы.

[lair]

Линейность нарушается. Всего этого можно было бы избежать, имея тесты на мастере.

[leninlin]

Суть в том что надо рассматривать staging именно как будущий master и вести его так что бы его в любой необходимый момент можно было выкатить. Если на master'е проводить тесты, то они будут полностью дублировать тесты со staging'а. Это может очень сильно увеличить время деплоя. В нашем случае master служит только как метка для понимания того что сейчас на продакшене. Таким образом важной веткой за которой действительно надо следить становится staging.

[lair]

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

[leninlin]

Не спорю, нужен. Надеюсь в скорое время будет.

[larikov]

Еще вопрос — как вы делаете откаты ошибочного функционала?

[leninlin]

Если срочно, то через capistrano делается rollback. В остальных случаях откатывается мерж коммит. Все мержи мы делаем с ключом --no-ff, поэтому они в истории в виде отдельного коммита, который можно дотаточно быстро откатить.

[script88]

почему не используете теги? после каждого релиза можно создавать теги, тем самым точно так же можно быстро откатывать функционал(кроме бд)

[leninlin]

Можно и теги, но откатываем не так часто, поэтому нет смысла давать каждому релизу имя когда обычно нужно откатить не больше 1-2 мержей.

[tangro]

У каждого в команде не больше 2-х рабочих инструментов

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

[leninlin]

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

Не просто так большинство сервисов стремятся к принципу «все в одном».

[tangro]

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

[zBit]

Git flow.
Есть ли смысл рассказывать об удобствах?

[leninlin]

Git flow это только идеология ведения git'а. Не спорю что здесь он присутствует, но акцент на связке с другими инструментами.

[t1gor]

CI постоянно мониторит гит репозиторий и по каждому комиту в тасковых ветках запускает процесс выполнения тестов.

А почему бы не сделать наоборот — git вызывает CI и прогонку тестов при выполнении каких-либо условий? В таком случае можно значительно снизить нагрузку на сам CI сервер, как мне кажется.

[leninlin]

Для этого git должен уметь обращаться по api к CI. Не везде есть интеграция c api конкретного используемого CI. Придется писать дополнительный промежуточный скрипт. А вот мониторинг репозитория есть почти в каждом CI. Поэтому просто идем от того что проще.