Какие политики Регистрации нужно рассмотреть для управления версиями?

Некоторые правила, которым мы следуем в нашей компании:

• Зафиксируйте все изменения, относящиеся к одной и той же задаче, сразу (это поможет просмотреть изменения и будущие откаты или слияния, если это необходимо).
• комментарии на основе шаблонов (например: префикс всех комментариев кодом, который представляет, что было сделано, + для добавления, - для удаления, * для обновлений,! для важных изменений и т. д.).
• Очевидно, что всегда проверяйте код, который компилируется , и завершенные работы на главной линии.
• Ежедневная регистрация незаконченных работ в филиалах.

Не ломайте сборку! Конечно, нелегко найти автоматический способ проверить это и отклонить регистрацию.

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

Если вам действительно нужно, чтобы более 10 разработчиков проверяли код в одной ветке, мы Мы запустили политику электронной почты, при которой разработчик, регистрирующийся, предупреждает всех, что они регистрируются, чтобы никто не пытался обновить свою копию ветки во время проверки. Иногда мы '

Там, где я работаю над TFS, мы используем:

• Анализ кода
  • Это гарантирует, что весь код был скомпилирован на машине разработчика до того, как он был проверен в
• Ассоциация рабочих элементов.
  • Если вы внесли изменения, должна быть назначенная задача!
• Последняя сборка выполнена успешно
  • Использование сервера сборки TFS для проверки того, что текущий код в системе контроля версий скомпилирован на независимой машине.
• Комментарии к отметке регистрации (часть TFS Powertools - http://msdn.microsoft.com/en- us / teamystem / bb980963.aspx )
  • Приятно иметь возможность видеть сводку о проверке, не переходя к элементам работ

Откровенно говоря, чем меньше политик, тем лучше. Чем больше у вас политик, тем больше стимул НЕ использовать контроль версий. Затем происходит следующее:

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

На самом деле, я думаю, что ваши три политики регистрации уже слишком много. Например:

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

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