практика контроля версий

Question

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

Answer 1

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

Частные ветки: позволяют проверять и работать с кодом, пока вы идете, объединяя туда и обратно в подходящее время.

Shelvesets / pacakaged наборы изменений: позволяют хранить наборы изменений и отправлять их на проверку - чтобы убедиться, что они готовы к работе до регистрации.

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

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

Answer 2

Начните с переключения с VSS на что-то более надежное и многофункциональное. См. Как убедить компанию переключить свой контроль источника

Затем примените известные хорошие практики:

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

Теперь вы не будете "готовы к работе" на этом этапе: вам все еще понадобится пара недель для тестирования и исправления, прежде чем вы сможете развернуть. Сокращение этого времени - это здорово для вас и для вашего клиента, так что инвестируйте в:

• Высококачественные автоматизированные приемочные испытания.

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Answer 6

@ bpapa

Ночное резервное копирование рабочих папок на серверы предотвратит потерю рабочего дня.

@ tonyo

Давайте посмотрим, что документы с требованиями были заполнены на следующий день после того, как мы закончили кодирование. Это говорит вам о нашем управлении проектами?

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

Answer 7

Заходите рано и регистрируйтесь часто по двум основным причинам -

1 - это может упростить интеграцию кода

2 - если ваш компьютер взорвется, ваши недели работы не пройдут

Answer 8

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

Если вы работаете с новыми функциями в «ветвях функций» / «экспериментальных ветвях», тогда можно коммитировать код, который еще далек от завершения. (Когда функция завершена, вы фиксируете хороший результат в «стволе».)

Но вы не выиграете конкурс популярности, если добавите некомпилируемый / явно неработающий код в «ствол» или «ветвь релиза».

У прагматичных программистов есть книга под названием Прагматическое управление версиями с использованием Subversion , в которой есть раздел с советами о ветвях.

Answer 9

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

Я бы сказал, что лучшая практика заключается в том, что вы должны объединять только отдельные (т.е. отдельные) функциональные компоненты в верхней части дерева. Если вы существенно перекрываете дельты с одними и теми же исходными файлами, я думаю, что это «может» указывать на то, что где-то на линии произошел сбой в управлении проектами, и что эти разработчики должны были объединить свои изменения в отдельной ветви интеграции, прежде чем перейти к Основные источники. Отдельный разработчик, который говорит, что они тестировали свои устройства, не имеет значения, потому что то, что они тестировали, изменилось!

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

Answer 10

Я думаю, что это может быть контроль версий, который мы используем, VSS в сочетании с отсутствием времени на изучение ветвления. Мне очень нравится идея ночных проверок, чтобы помочь с разработкой и избежать 'Going Dark'. Я вижу, как он устойчив к стволам, но, возможно, строит SS для разработки, а когда код готов к работе, перенесет его в SS.