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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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