Непрерывная интеграция Workflow & SVN

обычно, при непрерывной интеграции, вся работа, выполняемая всеми разработчиками, выполняется на одной ветке (или на магистрали). Фактически, Subversion была разработана с учетом этого типа рабочего процесса. То, что все работают в одной отрасли, может показаться пугающим. В конце концов, как насчет конфликты? Что делать, если я хочу включить одну ошибку/улучшение/дополнение, но не другую в мой следующий выпуск?

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

если вы решите использовать частное ветвление, я бы рекомендовал вам настроить два Дженкинс экземпляров. Первым будет официальный один. Вы строите из ствола и ветвей выпуска, но не ветвей разработчика. Этот Дженкинс проведет все модульные тесты. Он будет хранить артефакты, необходимые для выпуска. Он доложит о результатах испытаний. Именно там ваша команда QA будет тянуть релизы для тестирования. Только вы можете настроить задания на этом Jenkins.

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

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

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

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

последний, как код размещается на сервере, является более загадочным. Мне нравится, когда Дженкинс создает артефакт доставки. Вы можете рассказать о том, что выпущено через номер сборки Jenkins.

"давайте выпустим сборку #25 на рабочем сервере."

"подождите, QA никогда не тестировал сборку #25, но они протестировали сборку #24."

"Хорошо, давайте выпустим сборку #24, я вижу, что в ней все равно есть проблема US232."

кстати, мы используем curl или команды wget чтобы вытащить программное обеспечение из Дженкинса и на наш сервер. На самом деле, у нас есть deploy.sh скрипт мы используем. Вы тянете deploy.sh скрипт от Дженкинса и запустите его. Это автоматически тянет вниз правую сборку из Дженкинс и устанавливает его. Он выключает сервер, создает резервные копии старой установки, устанавливает новое программное обеспечение, перезагружает сервер, а затем сообщает о результатах.

тем не менее, есть что-то в идее подрывной деятельности, делающей ваши поставки для вас. Используются различные методы. Один из них заключается в том, что Subversion автоматически выполняет обновление в определенное времяпроизводства филиала. Вы ставите код на производства филиала, и в 2:00 утра каждое утро, Subversion доставит ваш код. Это отличная идея, и я сделал это, особенно когда вы говорите о PHP, который не нужно компилировать.

Я предпочитаю первый метод, так как у вас больше контроля и заставляет вас развертывать только сборки Jenkins. Кроме того, обычно есть некоторые проблемы, которые вызовут обновление с SVN метод развертывания для сбоя (столкновение, неверсионный файл, который необходимо удалить и т. д.). И, конечно, это произойдет самое большее критическое время. И, конечно, это будет впечатляющий провал, который произойдет прямо перед тем, как ваш босс заполнит ваш ежегодный обзор.

так, в ответ на ваш третий вопрос. Мой предпочтительный метод - не вовлекать подрывную деятельность. Вместо Этого Я ... --5-->ftp построенные артефакты (используя wget и curl) непосредственно с сервера Jenkins и запустите истинный сценарий развертывания, который обрабатывает все, что требуется.

кстати, мы рассматриваем различные инструменты развертывания как LiveRebel это будет интегрироваться с Дженкинсом. Идея в том, что Дженкинс построит пакет доставки и развернет его в LiveRebel, затем он может использовать LiveRebel для развертывания его на наших серверах. Мы не уверены, будет ли каждая сборка Дженкинса развернута в LiveRebel, или мы будем использовать построить продвижение плагин, чтобы позволить QA выбрать сборки для развертывания в LiveRebel. Второй предотвратит развертывание сборок, которые QA не имеет проверенный.

дополнительное соглашение

Спасибо за ответ и понимание. причина, по которой я смотрел на ветвление каждой задачи, по ряду причин:

Я отвечу на каждую из ваших причин...

1) - позволяет выполнять задачи в изоляции от основной магистрали.

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

многие менеджеры любят думать, что эта изоляция позволит им выбирать, какие задачи включать в следующий выпуск, и они смогут сделать это во время выпуска. Один из первых истинных пакетов CM был назван Sablime от AT&T, и он был основан на этой самой философии.

в Sablime, у вас есть Generic что они называют релизе. Это основа для всех изменений. Каждое изменение назначено Запрос На Модификацию (г-н номер), и вся работа должна быть сделана на г-н

вы создаете следующий общий, взяв старый базовый общий, добавив в выбранный MRs и tada! Новый Generic может быть создан. Звучит просто: старая базовая линия + выбранные изменения = новая базовая линия.

к сожалению, MRs повлияет на файлы те же файлы. На самом деле, это не было редкостью для нового generic, чтобы содержать версию файла, который не был написан фактическим разработчиком. Кроме того, один мистер зависел от другого. Менеджер объявил бы, что миссис 1001, 1003 и 1005 были в следующем выпуске. Мы пытаемся добавить эти MRs в базовую линию, и мы обнаруживаем, что MR 1003 зависит от MR 1002, который также зависит от MR 1008, который мы не хотим выпускать. Мы проводим следующую неделю, пытаясь разработать набор освобождаемых MRs, и в конечном итоге выпускаем программное обеспечение, которое никогда не было тщательно протестировано.

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

2) нет ограничений по времени-каждая задача может занять свое время завершается, и не влияет на другие задачи.

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

все задачи имеют ограничение по времени, потому что существует стоимость, связанная со временем, и выгода, связанная с этой задачей. Задача, которая занимает много времени, но дает мало пользы, не стоит делать.

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

в гибкой разработке ни одна задача не должна занимать больше ресурсов, чем спринт можете себе позволить. (A спринт мини-релиз и обычно охватывает двухнедельный период.) В течение этого двухнедельного периода разработчик имеет определенное количество точки они могут выполнить (пункты это как-то связано с часами, но не совсем. Просто предположим, что одна точка представляет X часов работы для этого мысленного эксперимента.) Если разработчик может набрать 15 очков в неделю, задача, которая занимает 30 очков, слишком велика для спринта и должна быть разделена на подзадачи.

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

ничто из того, что я говорю, не означает, что вы не можете делать разработку на основе задач. Сайты, которые используют Git, делают это много. Гибкий процесс предполагает это. Ничто из этого не подразумевает, что вы вернетесь к методу водопада, где никому не разрешено прикасаться к клавиатуре, пока не будет выложена каждая мучительная деталь. Однако вы не можете просто выполнить пятьдесят отдельных задач, а затем за день до выпуска выбрать, какие из них вы хотите включить. Вы не освобождаете задачи, вы выпуск программного продукта.

использовать ветвление задач. Однако, насколько вы обеспокоены, задача не полное пока его изменения находятся в багажнике. Разработчики несут за это ответственность. Они должны!--5-->rebase (объединить изменения из ствола в ветви), испытания их перебазированы код, а потом поставить (объединить их изменения обратно в магистраль), прежде чем проект сможет считать эту задачу завершенной.

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

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

однако все изменения, которые вы делаете, не будут считаться частью Linux, пока эти изменения не будут возвращены в один и только официальный репозиторий Git.