Каковы рекомендации по управлению исходным кодом и управлению конфигурацией? - PullRequest
Новая
       62

Каковы рекомендации по управлению исходным кодом и управлению конфигурацией?

7 голосов
/ 15 апреля 2009

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

  1. Один скрипт сборки, такой как makefile , соберет и протестирует весь проект
  2. Все компоненты, необходимые для построения система должна контролироваться источником

У кого-нибудь есть такой список? В порядке очередности?

ОБНОВЛЕНИЕ - добавлено несколько деталей

Рассматриваемая система состоит из C ++ и make-файлов, Java с ant, который приводит к WAR, а также компонентов powerbuilder и C # gui. Весь код в исполнении.

Поэтому я ищу как общие, так и языковые рекомендации.

Ответы [ 8 ]

7 голосов
/ 15 апреля 2009

Для меня правило № 1 таково:

Основная ветвь является священной - она ​​всегда должна быть наращиваемой, способной передавать BVT и быть в основном пригодной для использования.

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

3 голосов
/ 15 апреля 2009
1 голос
/ 15 апреля 2009

Система должна строить сама, тестировать сама и загружать + строить зависимости самостоятельно. У меня есть make-файл, загружающий, создающий и внедряющий среду выполнения, которая «сертифицирована» для моей транковой версии. Этот make-файл также помещается в хранилище.

Не забудьте совершить еще одну, очень важную и в основном пропущенную вещь (входит в комплект из трех):

  • Код SQL, который создает макет вашей базы данных (поместите в него версию!).
  • Код SQL, который отображает версию макета вашей базы данных (для обновления)
  • Код SQL, который сбивает версию макета вашей базы данных (для понижения)
1 голос
/ 15 апреля 2009

Мой номер один:

  • Обновлять часто, совершать часто,

или, как говорит Джефф: Заезд рано, Заезд часто .

1 голос
/ 15 апреля 2009

Это сильно зависит от того, в какой среде вы строите?

  • Это C / MakeFile?
  • Это Java / JUnit / Ant?
  • Это .NET / NUnit / NAnt?
  • Это .NET / MSUnit / MSBuild?
  • Это Руби ...
  • Это Питон ...
  • Это PHP

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

0 голосов
/ 15 апреля 2009

Весь процесс «получения последних» и «строительства» должен быть плавным, легким, быстрым и надежным.

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

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

Вроде как философия Google, согласно которой загрузка \ установка должна быть быстрой и простой

0 голосов
/ 15 апреля 2009

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

Одна вещь, которую вы, возможно, захотите считать для меня важной (или # 1) в ЛЮБОМ списке, который вы собрали, заключается в том, что ствол или основная ветвь вашего инструмента ОЧЕНЬ жестко контролируются, и только очень немногие из них имеют доступ к импорту или внести изменения в него. Это сэкономит массу головных болей во время выпуска.

Элементы, которые могут быть в любом списке, который вы составляете:

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

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

0 голосов
/ 15 апреля 2009

Если вы пройдете эти вопросы из «Теста Джоэла», вы должны быть на правильном пути:

Используете ли вы контроль источника?
Вы делаете ежедневные сборки?
У вас есть база данных об ошибках?
Вы исправляете ошибки перед написанием нового кода?

Мой # 1: вы можете сделать сборку за один шаг?

Тест Джоэла

...