Стратегия выпуска проекта / кода

У вас есть большая тройка: контроль версий, сборка в один клик через Maven и ваш сервер непрерывной сборки, а также отслеживание ошибок. Похоже, вы, ребята, тяготеете к методологиям Agile, и поэтому вам следует всегда стараться поддерживать основную версию вашего продукта в состоянии, близком к доставляемому.

Когда вы решите выпустить свой первый выпуск, создайте ответвление от основной версии для этого выпуска. Определитесь со схемой маркировки и обязательно пометьте версию ветки. Например, вашим первым выпуском может быть 1.0.4530, где 1 означает первую версию, 0 означает, что это первый кандидат на выпуск, а 4530 - это номер изменения управления версиями. Вы тестируете эту ветку выпуска и исправляете в ней важные ошибки. Через некоторое время вы выпускаете другого релиз-кандидата, скажем, 1.1.4807. Этот процесс повторяется еще пару раз (скажем), ваш выпуск становится достаточно хорошим, и вы выпускаете версию 1.3.5167.

Между тем, ваша новая разработка происходит только в основной версии, и время от времени вам нужно будет переносить исправления ошибок из ветки выпуска 1.x обратно в магистраль. Позже вы отделите ветку 2.x от основной ветки, чтобы повторить процесс для вашего второго выпуска. Как правило, у вас будет несколько активных веток (плюс ствол), при этом разработка будет ограничена стволом, и каждая ветка останется нетронутой и независимой от разработки.

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

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

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

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

Похоже, разработчикам нужно использовать «тестовые ветки» и немного больше уважать «стабильную / производственную ветвь».

Продавайте в соответствии с концепцией «делайте в этой ветке свои дела, связанные с диким западом», и когда вы довольны результатами, вы объединяете ее в эту «скучную стабильную производственную ветку» .... (или что-то в этом роде)

Есть книги, написанные на общую тему; Поиск Amazon даже возвращает три названия для специализированного «контроля версий с помощью git».

Я думаю, вам будет полезно определить канонический взгляд на кодовую базу. Назовите это тестом. Проблема - это проблема, если она появляется в Test. Если проблема не проявляется в представлении какого-либо разработчика, этот разработчик должен выяснить, в чем заключается важное различие; и то же самое для проблемы, которая появляется в представлении разработчика, но не в Test.

Согласно одному соглашению, Test будет перестраиваться из исходников каждую ночь. Более жесткое соглашение состоит в том, чтобы Test перестраивался при каждом обновлении. Если ваша команда небольшая (пять или меньше) и не рассредоточена на больших расстояниях или в нескольких часовых поясах, разумное первое приближение состоит в том, чтобы протестировать рабочую область git на сервере, на котором была установлена ​​ваша инструментальная цепочка вместе с некоторыми заданиями cron, чтобы это рабочее пространство обновляется и перестраивается каждую ночь (обычно).