Вернуться к основам: что такое хороший процесс регистрации?

Question

Моя команда в основном работала над нашими собственными проектами.Я пишу код, проверяю его в системе контроля версий и редко кто-нибудь еще видит его (кроме конечного продукта).Все остальные следуют тому же основному потоку.

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

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

На мой взгляд, процесс будет похож на ...

1. Перед регистрацией, подтвердите, что ваш код создается и выполняется локально.
2. Получить последний.
3. Вручную разрешать любые конфликты.
4. Убедитесь, что ваш материал собирается и выполняется локально, используя последние биты, полученные на предыдущем шаге.
5. Регистрация

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

Спасибо!

Answer 1

Я бы поставил против любой процедуры, которая предполагает, что пользователи будут следовать ей. Люди редко так делают. Но есть альтернатива, которая побуждает каждого делать то, что вы хотели (и больше, в зависимости от обстоятельств):
1. Настройте сервер непрерывной интеграции и настройте его для компиляции и запуска своего кода (того же кода, который, как вы ожидаете, ваши парни будут «выполнять локально»).
2. Сделать позорным, чтобы сломать сборку. Это зависит от культуры; иногда достаточно просто поделиться статистикой, иногда вам нужно отправить электронное письмо непосредственному руководителю, который сломал сборку, что угодно.

При этой процедуре, если она реализована правильно, все будут делать то, что нужно (например, если не делать get-latest рискованно, они научатся делать это со временем).

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

Answer 2

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

Должно быть очень мало конкретных правил относительно коммитов.Мне нравятся эти правила:

1. Не фиксируйте испорченный код.Он должен компилироваться и запускаться, как и ожидалось.
2. Будьте внимательны при слиянии.

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

• SCM отправляет коммиты различий сразу всей команде, как только происходит коммит.
• Непрерывная интеграция создается немедленно.По моему опыту, проверка на изменение каждые 15 минут не достаточно.Либо запускайте сборку CI через ловушку, либо проверяйте каждые 1-5 минут на наличие изменений.
• Сделайте историю коммитов легко доступной через браузер.

Мне также нравится подписывать каждую фиксациюот другого члена команды.Некоторые системы SCM могут помочь с этим рабочим процессом.

Answer 3

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

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

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