Комментарии 1
Хм, на моей текущей работе такое TBD где-то с 2012. Хотя у некоторых задач могут делать в релизной ветке и потом переносить в транк, разница несущественна.
В качестве основы Gerrit. На нём плодить множество персональных веток неудобно, а вот такие короткоживущие ветки у него естественно возникают в виде какого-нибудь refs/changes/41/245241/1 внутри его хранилища (ветка — когда несколько таких коммитов в цепочке). Легко подключается CI (используем Jenkins) с простановкой оценок (тесты прошли — Verified:+1, не прошли — Verified:-1, коммитить нельзя). Peer review (по умолчанию, для разрешения мержа в основную ветку нужно не менее одного +2 при отсутствии -2). Связь с тикетами через идентификаторы тикетов в commit message.
В нашем отделе полиси разрешает мержить в самом gerrit, если fast forward не проходит, но не разрешает отправлять merge commits. Это иногда чревато поломкой по тестам, выясняется на еженощном запуске. В одном из соседних наоборот — можно постить merge commits от себя (и они проверяются через CI), но нельзя мержить в самом сервере. Но у них очень мало коммитов, а каждый сам по себе сильно сложнее — им таки так лучше.
Есть список активных релизных веток, в которые должны попасть все исправления, которые не конфликтуют с их целями — обычно это 1-2 LTS и одна текущая не-LTS. В неё переносятся коммиты черипиками. У вас такое, если это сайт, вряд ли будет, а у нас appliances клиентов, нам важно.
В общем, не вижу ничего нового в этом подходе. Но, подозреваю, таких как мы с подобным подходом реально мало.
Ну и заметная часть остального есть — иерархия задач (хотя для долгоживущих в ней смысла нет, главное — задача не пересекает момент форка конкретного релиза) и time-based релизная политика (что успели — то успели, ok, всё равно в релиз попало 100500 новых фич).
В качестве основы Gerrit. На нём плодить множество персональных веток неудобно, а вот такие короткоживущие ветки у него естественно возникают в виде какого-нибудь refs/changes/41/245241/1 внутри его хранилища (ветка — когда несколько таких коммитов в цепочке). Легко подключается CI (используем Jenkins) с простановкой оценок (тесты прошли — Verified:+1, не прошли — Verified:-1, коммитить нельзя). Peer review (по умолчанию, для разрешения мержа в основную ветку нужно не менее одного +2 при отсутствии -2). Связь с тикетами через идентификаторы тикетов в commit message.
В нашем отделе полиси разрешает мержить в самом gerrit, если fast forward не проходит, но не разрешает отправлять merge commits. Это иногда чревато поломкой по тестам, выясняется на еженощном запуске. В одном из соседних наоборот — можно постить merge commits от себя (и они проверяются через CI), но нельзя мержить в самом сервере. Но у них очень мало коммитов, а каждый сам по себе сильно сложнее — им таки так лучше.
Есть список активных релизных веток, в которые должны попасть все исправления, которые не конфликтуют с их целями — обычно это 1-2 LTS и одна текущая не-LTS. В неё переносятся коммиты черипиками. У вас такое, если это сайт, вряд ли будет, а у нас appliances клиентов, нам важно.
В общем, не вижу ничего нового в этом подходе. Но, подозреваю, таких как мы с подобным подходом реально мало.
Ну и заметная часть остального есть — иерархия задач (хотя для долгоживущих в ней смысла нет, главное — задача не пересекает момент форка конкретного релиза) и time-based релизная политика (что успели — то успели, ok, всё равно в релиз попало 100500 новых фич).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Trunk-Based Development: как мы внедряем разработку на основе главной ветки