Какая часть вашего проекта должна быть в контроле исходного кода?

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

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

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

Я бы сказал, что минимум, который должен содержать исходный контроль, - это все файлы, необходимые для воссоздания работающей версии проекта. Это даже включает файлы DDL для установки и изменения любой схемы базы данных, и в правильной последовательности тоже. Минус, конечно, инструменты, необходимые для сборки и выполнения проекта, а также все, что может быть автоматически получено / сгенерировано из других файлов в системе контроля версий (таких как файлы JavaDoc, созданные из файлов Java в системе управления версиями).

Лучше всего поместить все под солнцем в систему контроля версий.

• Код

• Библиотеки

• Ресурсы

• Сценарии сборки / развертывания

• Сценарии создания и обновления базы данных

• Некоторая документация

• Конфигурационные файлы для конкретной среды

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

Я бы сказал, что;

• любой файл, необходимый для сборки, попадает в систему контроля версий
• любой файл (который может быть), сгенерированный сборкой, не

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

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

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

Некоторые из ответов здесь говорят «не помещайте двоичные файлы в систему контроля версий». Это неверно. Когда вы работаете над продуктом с большим количеством стороннего кода и множеством двоичных библиотек от поставщиков, вы включаете двоичные библиотеки . Потому что, если вы этого не сделаете, то в какой-то момент вы собираетесь выполнить обновление, и у вас возникнут проблемы: сборка будет прервана, потому что сборочная машина не имеет последней версии; кто-то дает новому парню старые компакт-диски для установки; в вики проекта есть устаревшие инструкции относительно того, какую версию устанавливать; и т.д. Хуже того, если вам нужно тесно сотрудничать с поставщиком для решения конкретной проблемы, и они отправляют вам пять наборов библиотек в неделю, вы должныбыть в состоянии отследить, какой набор двоичных файлов показал, какое поведение. Система контроля версий - это инструмент, который решает именно эту проблему.

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

А что происходит, когда разные проекты требуют разных наборов инструментов? Пример: через пару лет один из проектов получил обновление от поставщика, и все Makefile сломались. Оказывается, они полагались на более новую версию GNU make. Так что мы все обновились. Упс, все файлы Makefile другого проекта сломались. Урок: зафиксируйте обе версии GNU make и запустите версию, которая поставляется вместе с вашим проектом.

Или, если вы работаете в месте, где все остальное совершенно неконтролируемо, у вас возникают разговоры типа: «Эй, новый парень начинается сегодня, где CD для компилятора?» «Не знаю, не видел их с тех пор, как Джек ушел, он был хранителем компакт-дисков». "Э-э, разве не до того, как мы поднялись со 2-го этажа?" «Может быть, они в коробке или что-то в этом роде». И поскольку инструментам уже три года, нет надежды получить этот старый CD у продавца.

Все ваши сценарии сборки принадлежат системе контроля версий. Все! Все вплоть до переменных среды. Ваша сборочная машина должна иметь возможность запускать сборку любого из ваших проектов, выполняя один скрипт в корневом каталоге проекта. ( ./buildявляется разумным стандартом; ./configure; makeпочти так же хорош.) Скрипт должен настроить среду как требуется, а затем запустить любой инструмент, который собирает продукт (make, ant и т. д.).

Если вы думаете, что это слишком много работы, это не так. Это на самом деле экономит массу работы. Вы фиксируете файлы один раз в начале времени, а затем при каждом обновлении. Ни один одинокий волк не может обновить свою машину и зафиксировать кучу исходного кода, который зависит от последней версии какого-либо инструмента, нарушая сборку для всех остальных. Когда вы нанимаете новых разработчиков, вы можете сказать им, чтобы проверить проект и запустить ./build. Когда версия 1.8 имеет много настроек производительности, и вы настраиваете код, флаги компилятора и переменные среды, вы хотите убедиться, что новые флаги компилятора не будут случайно применены к сборкам патчей версии 1.7, потому что им действительно нужен код изменения, которые сопровождают их, или вы видите некоторые волосатые расы.

Лучше всего , это когда-нибудь спасет вашу задницу: представьте, что вы отправите версию 3.0.2 вашего продукта в понедельник. Ура, празднуем. Во вторник утром VIP-клиент звонит на горячую линию поддержки, жалуясь на эту сверхкритическую, срочную ошибку в версии 2.2.6, которую вы отправили 18 месяцев назад. И вам по-прежнему приходится поддерживать его по контракту, и они отказываются обновляться, пока вы не сможете точно подтвердить, что ошибка исправлена ​​в новом коде, и они достаточно велики, чтобы заставить вас танцевать. Есть две параллельные вселенные:

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

• Во вселенной, где все находится под контролем исходного кода, вы проверяете тег 2.2.6, готовите отладочную сборку примерно через час, тратите день или два на воссоздание «VIP ошибки», отследите причину, устраните ее текущий выпуск, и убедить клиента обновить. Напряженный, но не такой ужасный, как в другой вселенной, где ваша волосная линия на 3 см выше.

С учетом сказанного, вы можете зайти слишком далеко:

• У вас должна быть установлена ​​стандартная ОС, у вас есть «золотая копия». Документируйте это, вероятно, в README, который находится в системе контроля версий, чтобы будущие поколения знали, что версия 2.2.6 и более ранние версии построены только на RHEL 5.3 и 2.3.0, а позднее - только на Ubuntu 11.04. Если вам легче управлять цепочкой инструментов таким образом, сделайте это, просто убедитесь, что это надежная система.
• Проектная документация громоздка в системе контроля версий. Документы по проектам всегда опережают сам код, и нередко приходится работать с документацией для следующей версии, работая над кодом для текущей версии. Особенно, если все ваши проектные документы являются бинарными документами, которые вы не можете изменить или объединить.
• Если у вас есть система, которая контролирует версии всего, что используется в сборке, используйте ее ! Просто убедитесь, что синхронизировать всю команду легко, чтобы все (включая сборочную машину) использовали один и тот же набор инструментов. (Я имею в виду такие системы, как pbuilder в Debian и ответственное использование python's virtualenv.)

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

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

Другими словами, все, кроме ОС, приложений и инструментов, должно быть в VCS и во встроенных системах, где может существовать зависимость от конкретной двоичной версии инструмента, я также видел инструменты, хранящиеся в VCS!

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

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

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

Drupal использует git, поэтому я буду использовать терминологию git. Я бы использовал подпункты для каждого модуля, чтобы иметь возможность получать обновления модулей из официальных репозиториев drupal, сохраняя при этом структуру отдельных развертываний. Таким образом, вы получаете преимущества сценариев, не теряя преимущества контроля всего исходного кода.

Все должно быть под контролем источников, кроме:

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

Подумайте об этом так: каждый новый член команды должен иметь возможность получить рабочую копию проекта (без элементов конфигурации).

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

@maple_shaft поднимает важную проблему с моим первым утверждением о файлах конфигурации среды в комментариях. Я хотел бы уточнить, что мой ответ заключается в специфике вопроса, который касается Drupal или общих проектов CMS. В таких сценариях у вас обычно есть локальная и производственная база данных, и один из параметров конфигурации среды - это учетные данные для этих баз данных (и аналогичные учетные данные). Желательно, чтобы они НЕ находились под контролем источников, так как это могло бы создать несколько проблем безопасности.

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

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

Например, следующее не входит в систему контроля версий:

• сгенерированный код
• сгенерированные двоичные файлы
• все, что создано вашей сборкой
• все, что создано во время выполнения вашим сервисом, процессом, веб-приложением

Что входит в систему контроля версий:

• любое действие человек создает
• все, что создано другим человеком или группой (например, сторонняя внутренняя библиотека, в которой распространяется управление исходным кодом, или двоичные файлы проекта с открытым исходным кодом).
• сценарии и другие источники, которые создают такие вещи, как база данных (то есть, как бы вы воссоздали БД, если бы все АБД выходили из-под контроля).

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

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

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

Журналы сборки и другие вещи, которые, вероятно, никого не интересуют (но вы никогда не знаете наверняка), обычно лучше всего отслеживаются теми, кто их генерирует: Дженкинс и т. Д.

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

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

Мой ответ довольно прост: не двоичные файлы. Подразумевается почти все остальное.

(Определенно, это не резервные копии базы данных, не миграция схем и не пользовательские данные.)

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

Контроль версий не является бесплатным. Это усложняет ваш рабочий процесс и требует обучения новых коллег. Взвесьте преимущества против стоимости.

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

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

Вещи я бы не поставил в систему контроля версий:

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

Так что я не делаю, hg addremoveнапример, так как время от времени при обновлении SDK создаю новый клон. Это также заставляет меня делать полное резервное копирование каждый раз, когда обновляется SDK, и проверять, что новая версия, клонированная из хранилища, исправна.

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

Непрерывная доставка: надежные выпуски программного обеспечения благодаря автоматизации сборки, тестирования и развертывания . В частности, в главе 2 рассматриваются элементы, которые должны быть помещены в систему управления версиями, что, как говорили многие, это практически все, кроме в основном сгенерированного контента в результате сборки.

Я не согласен с одной частью принятого ответа, предоставленного @FrustratedWithFormsDesigner меньше, потому что он выступает за то, чтобы не включать в систему контроля версий инструменты, необходимые для создания проекта. Где-то в управлении исходным кодом (рядом со строящимся кодом) должны быть сценарии сборки для сборки проекта и сценарии сборки, которые запускаются только из командной строки. Если под инструментами, которые он имеет в виду, IDE и редакторами, от них вообще не требуется создавать проект. Они хороши для активной / быстрой разработки для разработчиков, и настройка среды этого типа может быть также написана по сценарию или загружена из другого раздела SCM или с некоторого типа двоичного сервера управления, и настройка таких IDE должна быть максимально автоматизированной.

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

Храните весь код в системе контроля версий, а также все настройки и пользовательские данные. Чтобы быть специфичным для drupal, вам нужно поместить все в контроль версий, кроме файлов и settings.php