Использование какой бы то ни было стратегии без понимания какие проблемы она решает и какие недостатки и ограничения имеет тоже не самый лучший вариант. У нас были прецеденты, когда люди использовали гит и git-flow, но совершенно не понимали зачем. И на самом деле им это было не нужно. Мастера с тегами хватало за глаза.
Выбор стратегии — это больная тема. После некоторых реформ мы для себя выбрали слегка расширенный GitFlow, так как стратегии "хватит мастера" и "каждому заказчику по ветке" совсем не работали и создавали еще больше хаоса. Пришлось некоторых долго обучать
ThreeFlow для нас не подходит, так как есть внешние зависимости и инсталляции очень старых версий, которые по лицензионным причинам получают только критические фиксы, но никак не новые фичи. Хотя для новых продуктов есть мысль использовать ***Flow: по ветке на каждое окружение на котором будет выполняться код. Например, dev, alpha, beta, pre-release, release. 5 веток лишь для примера, каждый может для себя разыграться от OneFlow, и только ставить тэг на то, что пошло в продакшен, или 100500Flow, если хватит ресурсов компании. :)
И да, интеграция feature веток может быть болью (но мы не испытываем проблем с этим, главное интегрироваться часто), но и отключенная флагом функциональность тоже может принести немало боли, когда код покрывается if-ами, конфиги флагами, и неявно влияет на выполнение включенного.
Выложить скрипт просто так не могу: собственность компании. Я поговорю с шефом по поводу открытия кода на гитхабе, но там нет ничего особенного и сверхъестественного, так собрание мини-хаков и гит-трюков.
У нас jira + java + maven + gitlab. Приведу пока описание без кода, что было сделано.
Скрипт в целом параметризован с помощью getopts. Он вызывает процедуры в порядке, необходимом для получения состояния в соответствии с правилами git-flow.
Версии. Тут мы пользуемся функциональностью maven versions:set/commit и help:evaluate для project.version. Потом можно просто использовать git tag -m "$ticket" -m 'Release 1.2' $version. Аналогично для веток.
Слияние работает только если нет конфликтов. Чтобы избежать очевидных конфликтов как то начало релиза 1.2.0-SNAPSHOT и переход к 2.0.0-SNAPSHOT в разработке. Очевидно, что при слиянии веток у нас будут конфликты в pom.xml. Можно автоматически слить ветки используя стратегию ours. Тогда конфликты проигнорируются при последующих слияниях.
Jira. У нее есть Rest API которое можно дернуть, чтобы залогиниться и получить заголовок по номеру задачи. Этой функциональностью мы пользуемся, чтобы при автоматических операциях проставить например, PRJ-1234 Hotfix 1.2.3
Gitlab. У него также есть Rest API. Им мы пользуемся для того, чтобы защитить ветку в начале разработки. Например release/1.2. Скрипт вызывает функцию типа gitlab_api release/1.2 protect.
custom hooks. Тут написан простой рецепт на ruby — я вообще начинал с примеров. Там есть конфигурация, какой идентификатор проекта и что проверять. Скрипт просто собирает регулярное выражение с возможными названиями веток и проверяет подходит ли присланная ветка под шаблон. Наряду с этим скрипт смотрит, чтобы в каждом присланном коммите был тикет типа PRJ-\d+, пустая вторая строка и первая строчка не слишком длинная. Единственный трюк был — получить список именно новых коммитов.
idempotent. Где возможно старался сделать скрипт идемпотентным, чтобы можно было запускать подряд несколько раз, если слияние не удалось из-за конфликтов и пришлось их вручную разруливать (rerere тут не получилось заставить работать). Например, sed для того, чтобы обновить <tag>release-1.2.3</tag> на <tag>release-1.2.4</tag>.
Если компания даст добро, то переработаю скрипты и выложу на гитхаб. У нас заняла чуть больше года разработка этого скрипта. Писалось все в фоне и по мере необходимости.
Загвоздка тут, все это написано под конкретно наши нужды. Выделить общую часть будет сложно. Есть уже git-flow для bash, который уже многое делает, но нам нужны еще дополнительные фунуции и шаги
В базе у нас тоже git-flow, но слегка модифицированный. Добавили еще release ветку по принципу hotfix, но только от develop — для стабилизации. И еще support ветки, которые начинаются с какого-то тега в master, куда мы через cherry-pick переносим какие-то единичные критичные фиксы в минорный релиз прошлой мажорной версии.
Вокруг этого постепенно был написан скрипт который автоматизирует создание и завершение hotfix/release веток, проставляет версии, тэги, сливает, заливает, защищает, и т.п. Делает много рутинной работы. Наш начальник уже сам как-то пару релизов делал: gf -y -i 123 -a finish -b hotfix — закончить hotfix под тикетом 123, собрать локально и залить в репозиторий не переспрашивая.
Дополнительно к этому в gitlab используем защищенные ветки: develop, master, support, release, hotfix — только основная команда может в них мержить, аутсорс поставляет merge request'ы, которые мы проверяем и заливаем, если все хорошо на ревью. Плюс у нас еще есть custom hooks которые смотрят, чтобы ветки аккуратно назывались, например, feature/prjid-123-abc-def-xyz и в каждом коммите была ссылка на тикет типа PRJID-123.
Несмотря на все это есть еще простор для автоматизаций.
Как только доберемся до автоматического выкатывания пререлизной версии на тестовое окружение, то появится еще долгоживущие ветки типа pre-release.
Oracle так просто не разрешает распространять его продукты, если пользователь не принимает лицензию самостоятельно. И в данном случае Oracle предоставляет только openjdk образ, но не свой. Так что могут быть проблемы с лицензией.
Собрать свой образ с java или oracle-xe у себя дома и пользоваться — можно. Распространять — скорее нет (если ответ короткий).
Выложить скрипт просто так не могу: собственность компании. Я поговорю с шефом по поводу открытия кода на гитхабе, но там нет ничего особенного и сверхъестественного, так собрание мини-хаков и гит-трюков.
У нас jira + java + maven + gitlab. Приведу пока описание без кода, что было сделано.
getopts. Он вызывает процедуры в порядке, необходимом для получения состояния в соответствии с правилами git-flow.versions:set/commitиhelp:evaluateдля project.version. Потом можно просто использоватьgit tag -m "$ticket" -m 'Release 1.2' $version. Аналогично для веток.1.2.0-SNAPSHOTи переход к2.0.0-SNAPSHOTв разработке. Очевидно, что при слиянии веток у нас будут конфликты вpom.xml. Можно автоматически слить ветки используя стратегию ours. Тогда конфликты проигнорируются при последующих слияниях.gitlab_api release/1.2 protect.PRJ-\d+, пустая вторая строка и первая строчка не слишком длинная. Единственный трюк был — получить список именно новых коммитов.<tag>release-1.2.3</tag>на<tag>release-1.2.4</tag>.Если компания даст добро, то переработаю скрипты и выложу на гитхаб. У нас заняла чуть больше года разработка этого скрипта. Писалось все в фоне и по мере необходимости.
Загвоздка тут, все это написано под конкретно наши нужды. Выделить общую часть будет сложно. Есть уже git-flow для bash, который уже многое делает, но нам нужны еще дополнительные фунуции и шаги
В базе у нас тоже git-flow, но слегка модифицированный. Добавили еще release ветку по принципу hotfix, но только от develop — для стабилизации. И еще support ветки, которые начинаются с какого-то тега в master, куда мы через cherry-pick переносим какие-то единичные критичные фиксы в минорный релиз прошлой мажорной версии.
Вокруг этого постепенно был написан скрипт который автоматизирует создание и завершение hotfix/release веток, проставляет версии, тэги, сливает, заливает, защищает, и т.п. Делает много рутинной работы. Наш начальник уже сам как-то пару релизов делал:
gf -y -i 123 -a finish -b hotfix— закончить hotfix под тикетом 123, собрать локально и залить в репозиторий не переспрашивая.Дополнительно к этому в gitlab используем защищенные ветки: develop, master, support, release, hotfix — только основная команда может в них мержить, аутсорс поставляет merge request'ы, которые мы проверяем и заливаем, если все хорошо на ревью. Плюс у нас еще есть custom hooks которые смотрят, чтобы ветки аккуратно назывались, например, feature/prjid-123-abc-def-xyz и в каждом коммите была ссылка на тикет типа PRJID-123.
Несмотря на все это есть еще простор для автоматизаций.
Как только доберемся до автоматического выкатывания пререлизной версии на тестовое окружение, то появится еще долгоживущие ветки типа pre-release.
Я бы предложил использовать что-то из openjdk.
Oracle так просто не разрешает распространять его продукты, если пользователь не принимает лицензию самостоятельно. И в данном случае Oracle предоставляет только openjdk образ, но не свой. Так что могут быть проблемы с лицензией.
Собрать свой образ с java или oracle-xe у себя дома и пользоваться — можно. Распространять — скорее нет (если ответ короткий).