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

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

В чем я все еще не уверен, так это в организации нижележащего git-репозитория / репозиториев. В настоящее время мы используем один репозиторий с gitflow в качестве модели ветвления. Репозиторий содержит следующие части:

APICDNВеб-сайтПриложение для iPhone

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

Преимущество наличия всех этих приложений в одном репозитории - это очень простая начальная настройка для всех нас и гарантия того, что приложение iPhone и API работают вместе, если разработчик использует одну и ту же ветку на обоих серверах (Windows ) и среда разработки приложений (Mac) во время разработки / тестирования.

Однако, это не правильно. Как написано выше, таким образом мы вынуждены использовать git-теги, чтобы различать новые «сборки» для приложения и серверных приложений. Кроме того, мы всегда должны публиковать все три веб-приложения, даже если кто-то только исправляет или добавляет что-то в одно из них.

Вероятно, мы могли бы представить ветки разработки и master для каждого из этих приложений. Это позволило бы нам отказаться от использования тегов (которые в любом случае не масштабируются) и начать новый процесс доставки с каждым коммитом в одну из главных ветвей.

Боюсь, что это приведет прямо к хаосу из-за по крайней мере 8 «базовых» веток и бесчисленных исправлений и функциональных веток.

Поэтому я предпочитаю другой вариант: разделить его на 5 репозиториев. Один для каждого из приложений, один для утилит и других вещей, не связанных непосредственно с одним из них.

Что значит иметь смысл? Как ты это делаешь? Как это работает лучше для вас? Спасибо за отзыв.