Параллельная работа с кодом

Параллельная работа с кодом

При наличии нескольких команд, одновременно работающих над одним исходным кодом, нам неизбежно придется иметь дело с параллельными ветками кода в системе SCM (software configuration management). Есть много книг и статей, рассказывающих, как обеспечить одновременную работу с кодом для нескольких людей, поэтому я не буду вдаваться в детали. Вряд ли мне удастся добавить что-то новое. Однако я хотел бы вкратце поделиться наработками нашей команды:

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

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

• Создавайте новые ветки кода только тогда, когда это действительно необходимо. Хорошим практическим правилом будет создание новой ветки только при условии, если вы вынуждены нарушать стратегию использования текущий ветки. Если у вас есть сомнения, то не делайте ветвлений. Почему? Потому что каждое ветвление требует дополнительной работы и последующей поддержки.

• Используйте ветвление для разделения кода разных стадий разработки. Вы можете создать для каждой Scrum команды отдельную ветку разработки. Но если вы смешаете краткосрочные изменения с долгосрочными изменениями в одной и той же ветке, вам очень сложно будет выпускать небольшие заплатки!

• Чаще синхронизируйтесь. Если вы работаете в отдельной ветке, синхронизируйтесь каждый раз, когда вы хотите что-либо построить. Каждый день, когда вы начинаете работу, синхронизируйтесь с главной ветвью разработки, так чтобы ваша ветка была в адекватном состоянии и учитывала все изменения, сделанные другими группами. Даже если это приведет к кошмару слияния (merge-hell), учтите, что все могло бы быть еще хуже, если бы вы затянули слияние.