Все ли члены команды работают над всеми репозиториями?
Нет, только разработчики, работающие над конкретной версией проекта.
У всех ли членов команды есть доступы до всех репозиториев?
Права на чтение есть у всех разработчиков, права на запись делятся в зависимости от бэк/фронт репозиториев. Админские права есть у разработчика, отвечающего за данную версию.
Кто заводит ветки в репозиториях?
Ветки может заводить любой разработчик, одна задача — одна ветка.
Чья обязанность влить все в версию? Как убедиться, что все ветки всех репозиториев были слиты\приняты по данной версии?
За это отвечает ответственный за данную версию разработчик.
Не вижу смысла стопорить работу всех, и даже привлекать к этому какое-то дополнительное внимание. Фейл билда, например, release-ветки касается только людей, которые занимаются этой версией, они видят этот фейл и правят его. И вызван он кодом, который они сами и сделали. Разработчикам, которые в это время разрабатывают следующую версию продукта в develop-ветке, а по факту это просто новый функционал, который чаще всего не связан с функционалом, над которым сейчас работают в release-ветке, нет необходимости знать о фейлах в сборке release-ветки. Главное, они знают, что в итоге к ним смогут влить только «хороший» код. Для этого и нужен именно запрет.
до этого момента в develop эти баги все еще присутствуют?
Да, они присутствуют в develop'e, но это, в большинстве случаев, ни на что не влияет, от данной ветки мы хотим получить только работающий новый функционал. Проверка функционала по всему прокту происходит в ветке release. Выходит, что текущий релиз хотфиксами поправили, затем влили в девелоп, получили поправленный старый функционал плюс новый, и делаем новый release.
но это можно автоматизировать + подключить мутационные тесты как показатель качества юнитов
email/slack/telegram/etc или дашборд со статусом сборки
Это всё равно всё посторонние штуки, куда надо зайти и посмотреть, сами по себе они ничего не запретят. У нас настроен хук на слак, туда идут успешные и неуспешные сборки. По всем проектам по всем сборкам. Никто не смотрит.
а master ветка зачем?
Master — продакшен, release — потенциальный продакшен. Процесс у нас такой: готовим версию, например, третью, сделали, протегировали как 3.0, CI протестировал, развернули на тестинге. Тестировщики, менеджеры, в некоторых случаях и клиенты, могут зайти посмотреть что и как, если нашли дефекты — мы делаем хотфиксы в этот release, с тэгом 3.1, и т.д. В какой-то момент дефектов найти не смогут — вот этот тэг и будет сливаться в мастер и девелоп.
Чаще всего просто тесты не пишут
Это один из моментов, за которыми мы следим в пул реквестах, если есть ветка, то должны быть новые тесты.
это код фризы (например тегами) какой-то версии для стабилизации
Тэги делаем из ветки release в каждом репозитории проекта для дальнейшего интеграционного тестирования данной версии.
jenkins и так по пушу будет запускаться
Это так, но упавший билд не привлечёт внимание команды. Он виден только либо из самого Jenkins'a, либо из vcs, но заходить туда лишний раз никто не станет. На данном этапе, Jenkins запускается после пуша, т.е. изменения уже будут в develop'e, и их уже смогут себе спуллить.
а в каких ситуациях у вас подобное может происходить?
Да, это хотфиксы к текущей версии продукта, которую пытаемся сдать, а в это время в develop'е разрабатываем функционал для следующей версии. И, несмотря на то, что все хотфиксы также проходят через пул-реквесты и release тестируется, чтобы его влить в develop также делаем пул-реквест. Больше для проформы, но всё-таки.
Мы новые версии продукта начинаем из ветки develop, и очень важно, чтобы код в этой ветке не оказался бракованным из-за того, что кто-то решил сделать пуш с «безобидными» правками. Сейчас это невозможно, чтобы что-то попало в master/develop/release необходимо сделать пул-реквест с запуском Jenkins'а, даже если мы пытаемся влить уже протестированный release в develop.
conf.lua — хорошее дело, мерси.
Проверка пары последних версий тоже будет полезно, и вряд ли сильно усложнит работу, если, конечно, разработчики движка полностью его не переделывают от версии к версии.
1) Да, тоже этот момент не нравился, но сперва не придумал, как должно оно быть, чтобы и понятно было и выглядело нормально, а потом привык к тому, что есть и забыл.
2-3) Спасибо за ссылку, почитаю. И за «тест» на обратную совместимость) Надо будет найти пару предыдущих версий движка и на них проверять перед окончанием работ.
По мне, совершенно нормальная ситуация, что кому-то статья покажется сложной, кому-то простой, а кому-то придётся в самый раз. Мне нравится этот движок, отлично подходит для аркадного гейм-дева — и я пытаюсь участвовать в его развитии.
Совет про разбор отдельных интересных элементов игры вместо поверхностного описания всей игры — отличный, спасибо, как раз о чём я и думал для следующего раза.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Права на чтение есть у всех разработчиков, права на запись делятся в зависимости от бэк/фронт репозиториев. Админские права есть у разработчика, отвечающего за данную версию.
Ветки может заводить любой разработчик, одна задача — одна ветка.
За это отвечает ответственный за данную версию разработчик.
Да, они присутствуют в develop'e, но это, в большинстве случаев, ни на что не влияет, от данной ветки мы хотим получить только работающий новый функционал. Проверка функционала по всему прокту происходит в ветке release. Выходит, что текущий релиз хотфиксами поправили, затем влили в девелоп, получили поправленный старый функционал плюс новый, и делаем новый release.
До этого мы ещё не дошли.
Master — продакшен, release — потенциальный продакшен. Процесс у нас такой: готовим версию, например, третью, сделали, протегировали как 3.0, CI протестировал, развернули на тестинге. Тестировщики, менеджеры, в некоторых случаях и клиенты, могут зайти посмотреть что и как, если нашли дефекты — мы делаем хотфиксы в этот release, с тэгом 3.1, и т.д. В какой-то момент дефектов найти не смогут — вот этот тэг и будет сливаться в мастер и девелоп.
Это один из моментов, за которыми мы следим в пул реквестах, если есть ветка, то должны быть новые тесты.
Это так, но упавший билд не привлечёт внимание команды. Он виден только либо из самого Jenkins'a, либо из vcs, но заходить туда лишний раз никто не станет. На данном этапе, Jenkins запускается после пуша, т.е. изменения уже будут в develop'e, и их уже смогут себе спуллить.
Да, это хотфиксы к текущей версии продукта, которую пытаемся сдать, а в это время в develop'е разрабатываем функционал для следующей версии. И, несмотря на то, что все хотфиксы также проходят через пул-реквесты и release тестируется, чтобы его влить в develop также делаем пул-реквест. Больше для проформы, но всё-таки.
Проверка пары последних версий тоже будет полезно, и вряд ли сильно усложнит работу, если, конечно, разработчики движка полностью его не переделывают от версии к версии.
2-3) Спасибо за ссылку, почитаю. И за «тест» на обратную совместимость) Надо будет найти пару предыдущих версий движка и на них проверять перед окончанием работ.
Совет про разбор отдельных интересных элементов игры вместо поверхностного описания всей игры — отличный, спасибо, как раз о чём я и думал для следующего раза.