Управление сборками / Непрерывные лучшие практики Интеграции

Как Ваша команда обрабатывает Сборки?
Мы используем Круиз-контроль, но (из-за отсутствия знаний) мы сталкиваемся с некоторыми проблемами - замораживанием Кода в SVN - управление сборками
А именно, как Вы делаете доступными конкретный выпуск, когда в коде постоянно регистрируются?

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

10
задан Community 23 May 2017 в 12:01
поделиться

5 ответов

Я положительно удивлен, что это не дубликат, но я не могу найти другой.

Хорошо, вот соглашение. Они - двухлетние отдельные, но связанные вопросы.

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

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

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

Вы могли бы хотеть считать одно из "Прагматического Управления версиями" книги, и конечно материал на CI и Круиз-контроль на сайте Martin Fowler важны.

14
ответ дан 3 December 2019 в 20:07
поделиться

Длинная короткая история: Создайте ответвление, скопированное с соединительной линии и контроля/сборки Ваш выпуск на том ответвлении по серверу сборки.

Однако для получения до той точки полностью автоматизированным способом с помощью cc.net не легкая задача. Я мог сообщить подробности о нашем процессе сборки, если Вам нравится, но это является, вероятно, слишком мелкомодульным для этого обсуждения.

Я соглашаюсь с Charlie о наличии автоматической, повторяемой сборки с нуля. Но мы не делаем всего для "Непрерывной" сборки, только для Ночного, Беты, Еженедельно или Омеги (GA/RTM/Gold) сборки конечных версий. Просто, потому что некоторые вещи, как генерация документации, могут занять много времени, и для непрерывной сборки Вы хотите предоставить разработчику быструю обратную связь на результате сборки.

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

0
ответ дан 3 December 2019 в 20:07
поделиться

Взгляд на непрерывную интеграцию: лучшие методы, от Martin Fowler.

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

[Отредактированный]

Мы используем Круиз-контроль в качестве инструмента интеграции. Мы просто имеем дело с соединительной линией, которая является основным репозиторием Подверсии в нашем случае. Мы редко вытаскиваем новое ответвление для того, чтобы сделать новые карты истории, когда существует шанс сложных конфликтов. Обычно, мы вытаскиваем ответвление для выпуска версии и создаем сборку из этого и поставляем это нашей тестовой команде. Между тем мы продолжаем работу в соединительной линии и ожидаем обратной связи от тестовой команды. После того как все протестировали, мы создаем тег из ответвления, которое неизменно логически в нашем случае. Так, мы можем выпустить любую версию любое время любому клиенту в случае, если. В случае ошибок в выпуске мы не создаем тег, мы чиним вещи там в ответвлении. После получения всего зафиксированного и утвержденного тестовой командой, мы объединяем изменения назад, чтобы соединить магистралью и создать новый тег из ответвления, характерного для того выпуска.

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

Точно,

  • Мы создаем ответвления вручную, когда мы планируем следующий выпуск
  • Мы создаем ответвление для выпуска и исправляем ошибки в том ответвлении в случае, если
  • После получения всего хорошего мы делаем тег из того ответвления, которое логически неизменно
  • Наконец мы объединяем ответвление назад, чтобы соединить магистралью, если имеет некоторые меры/модификации
5
ответ дан 3 December 2019 в 20:07
поделиться

Управление версиями подходит вне непрерывной интеграции.

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

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

Непрерывная интеграция должна включать автоматический запуск модульных тестов также.

Кроме того, полный процесс управления версиями включит:

  • ряд развертывания на серверах гомологизации
  • полный цикл гомологизации / UAT (Тест Приемлемости для пользователя)
  • нерегрессионные тесты
  • производительность / стресс-тесты
  • подготовка производства (и параллель запускает тесты),

перед окончательным выпуском в производство.

Снова "управление версиями" намного более сложно, чем просто "непрерывная интеграция" ;)

2
ответ дан 3 December 2019 в 20:07
поделиться

Можно использовать Сервер Основы Команды 2008 и Microsoft Studio Team System для выполнения управления исходным кодом, ветвления и выпусков.

-2
ответ дан 3 December 2019 в 20:07
поделиться
Другие вопросы по тегам:

Похожие вопросы: