@aaltqna
Есть 2 основных ветки: master и dev. Процесс разработки такой: новая задача (task-1234) создается от master, разрабатывается и отправляется в dev, после в dev тестируется, закрывается в «тест среде» и сама задача (task-1234) отправляется в master. В dev можно пушить master. В master пушить dev нельзя. (можно это опустить и представить, что задачи вообще никуда не заливаются, а висят в ревью)
1) Простой пример: я имею 2 задачи — добавить index страницу ресурса Article и добавить crud кнопки на эту страницу для этого ресурса. Т.е. получается, что 2 задача зависит от первой. Первую я сделал и отправил в dev (или поставил на ревью), мне нужно приступать к второй сразу, ждать я не могу. Что мне делать?
2) Сложный пример: допустим, задач не 2, а 20. Это разработка большого модуля, часть задач являются подзадачами, часть просто зависимы от других. Как быть здесь?
II.
Я столкнулся с 2 примером и мне пришлось создавать зависимости между задачами, создавать одни на основе других и следить за изменениями в каждой, чтобы после обновлять зависимые. Все это мерджилось на dev, потом чистилось от того, что dev мерджился в них. Пришлось решать кучу конфликтов, а после еще и создавать одну результирующую задачу, в которую я замерждил всю эту кучу задач, решил все конфликты и именно ее отправил на master.
III.
После я нашел это: https://softwareengineering.stackexchange.com/a/351790, но не до конца пока это понял.
IV.
Поэтому пытаюсь понять, как я все же должен поступить в итоге, если снова столкнусь с кучей задач, которые частично связаны друг с другом. Есть ли универсальное решение такой проблемы?
V.
И доп. вопрос, вот ведение независимого master от dev очевидно имеет минусы. Gitflow предлагает делать резизы именно из dev, но вариант с релизами нам не подходит, т.к. из требований — непрерывная разработка. Чтобы задача выполнялась и могла быть сразу протестирована и отправлена на master. Есть ли для этого какие-то адекватные решения?
Решения вопроса 0
Ответы на вопрос 2
@d-stream
master == прод
dev == ветка стабильной разработки, где живут более-менее целостные фичи
feature_xx == опять же целостная, самостоятельная фича, привносящая осмысленный функционал и состоящая возможно из множества задач
фичи отращиваются и возвращаются в ветку dev и их можно даже на уровне ветки протестировать
в какой-то момент от ветки dev отращивается ветка release (по-сути релиз-кандидат) и потом по выпуску (релизу) вливается в master и dev
go to 1
при таком подходе в dev живёт достаточно стабильное решение, а ветках feature — конкретные фичи, которые к моменту влития в dev — в общем-то тоже стабильны и функциональны.
ну и собственно релизный цикл получает некую «асинхронность» относительно цикла разработки:
— захотел релиз-менеджер к юбилею фирмы выпустить релиз — пожалуйста — в dev есть пачка фич
— накопилось осмысленное кол-во фич — вперёд в релиз
— оттестирована конкретная ожидаемая фича — в релиз (ну и попутно менее значимые)
сорри за слегка вольный пересказ по-сути большинства моделей ветвления гита, гитлаба, атлассиана и др.)
@aaltqna
parent-1
child-1
child-child-1
child-child-2
child-2
child-3 (по описанию требует код child-child-1)Допустим, добавляется новый модуль, менеджер задач поддерживает иерархию, тогда:
I. Разработка.
1) создаю parent-1, в ней добавляется общий код.
2) на основе parent-1 создаются child-1..3
2.1) если в parent-1 происходят ЛЮБЫЕ изменения, то в каждом ее child я делаю rebase от измененной parent-1.
3) на основе child-1 создаются child-child-1..2
3.1) если в child-1 происходят ЛЮБЫЕ изменения, то в каждом ее child я делаю rebase от измененной child-1.
4) child-3 требует код child-child-1. Я делаю merge child-child-1 в child-3 и ставлю в менеджере задач, что child-3 блокируется child-child-1.
4.1) если в child-child-1 происходят ВАЖНЫЕ для child-3 изменения, то я снова делаю merge child-child-1 в child-3
4.2) если в child-child-1 происходят НЕВАЖНЫЕ для child-3 изменения, то я не делаю merge вообще
II. Доставка.
Сценарий 1) непрерывный вывод каждой задачи, тогда child-1 и child-2 и все их подзадачи доставляются сразу после закрытия их в тест среде как master merge сhild-n (child-child-n).
child-3, как имеющий зависимость, ожидает доставки своих зависимостей и только потом может быть доставлен сам.
Сценарий 2) релиз тип, модуль должен быть доставлен разом. Тогда создается еще одна результирующая задача (release-1) в нее вливаются все конечные узлы каждой parent-1 подзадачи.
Здесь можно выделить отдельной задачей частичный релиз, выбрав только часть подзадач parent-1.
В результате имеются изолированные задачи с конкретными зависимостями и 2 вариантами доставки. Теоритически с доп. информацией пришел к такой системе. Минусы?