Вы в некотором роде, но я бы немного расширил вашу диаграмму:
По сути (если ваш контроль версий позволит это, т.е. если вы используете hg / git), вы хотите, чтобы у каждой пары разработчик / разработчик была своя «личная» ветвь, которая содержит отдельную историю пользователя, над которой они работают. Когда они завершают функцию, они должны нажать на центральную ветвь, ветвь «Освобождение». На этом этапе вы хотите, чтобы разработчик получил новую ветку, для следующего, над чем им нужно работать. Исходная ветвь объекта должна быть оставлена как есть, поэтому любые изменения, которые необходимо внести в нее, могут быть сделаны изолированно (это не всегда применимо, но это хорошая отправная точка). Прежде чем dev вернется к работе над старой веткой функций, вы должны добавить ветку последней версии, чтобы избежать странных проблем слияния.
На данный момент у нас есть возможный кандидат на выпуск в виде ветки «Release», и мы готовы запустить наш CI-процесс (в этой ветке, очевидно, вы можете сделать это в каждой ветке разработчика, но это довольно редко в больших командах разработчиков это загромождает CI-сервер). Это может быть постоянный процесс (в идеале, CI должен запускаться всякий раз, когда изменяется ветвь "Release"), или это может происходить ночью.
На этом этапе вы захотите запустить сборку и получить жизнеспособный артефакт сборки с CI-сервера (то есть то, что вы могли бы развернуть). Вы можете пропустить этот шаг, если вы используете динамический язык! После того, как вы соберетесь, вы захотите запустить свои модульные тесты, поскольку они являются основой всех автоматизированных тестов в системе; они, вероятно, будут быстрыми (что хорошо, поскольку весь смысл CI заключается в сокращении цикла обратной связи между разработкой и тестированием), и вряд ли им потребуется развертывание. Если они пройдут, вы захотите автоматически развернуть свое приложение на тестовом сервере (если это возможно) и запустить все имеющиеся интеграционные тесты. Интеграционные тесты могут быть автоматизированными тестами пользовательского интерфейса, тестами BDD или стандартными интеграционными тестами с использованием инфраструктуры модульного тестирования (т. Е. «Unit»).
К этому моменту у вас должно быть достаточно полное указание на жизнеспособность сборки. Последний шаг, который я обычно настраиваю с помощью ветки «Release», - это автоматическое развертывание кандидата на выпуск на тестовом сервере, чтобы ваш отдел контроля качества мог проводить ручные дымовые тесты (это часто делается ночью, а не для каждой проверки, чтобы чтобы не испортить тестовый цикл). Это просто дает человеку быстрое представление о том, действительно ли сборка действительно подходит для живого релиза, так как довольно легко пропустить что-то, если ваш тестовый пакет не является исчерпывающим, и даже при 100% охвате тестированием легко пропустить то, что вы можете не проверять автоматически (например, неправильно выровненное изображение или орфографическая ошибка).
Это действительно комбинация непрерывной интеграции и непрерывного развертывания, но, учитывая, что в Agile основное внимание уделяется бережливому кодированию и автоматизированному тестированию как первоклассному процессу, вы хотите стремиться получить как можно более комплексный подход.
Процесс, который я описал, является идеальным сценарием, есть много причин, по которым вы можете отказаться от некоторых его частей (например, ветки для разработчиков просто невозможны в SVN), но вы хотите стремиться к как можно большей его части. ,
Что касается того, как цикл Scrum-спринта вписывается в это, в идеале вы хотите, чтобы ваши релизы происходили как можно чаще, а не оставляли их до конца спринта, чтобы получить быструю обратную связь относительно того, есть ли функция (и собрать в целом). ) является жизненно важным средством для сокращения цикла обратной связи с владельцем продукта.
Концептуально да. Диаграмма не захватывает много важных моментов, таких как:
источник
Вы можете нарисовать более широкую систему для диаграммы. Я хотел бы рассмотреть возможность добавления следующих элементов:
Покажите ваши входы в систему, которые передаются разработчикам. Назовите их требованиями, исправлениями ошибок, историями или чем-то еще. Но в настоящее время ваш рабочий процесс предполагает, что зритель знает, как эти входы вставляются.
Показать контрольные точки вдоль рабочего процесса. Кто / что решает, когда разрешено изменение в trunk / main / release-branch / etc ...? Какие кодовые деревья / проекты строятся на СНГ? Есть ли контрольная точка, чтобы увидеть, была ли нарушена сборка? Кто выпускает из СНГ для постановки / производства?
С контрольными точками связано определение вашей методологии ветвления и того, как она вписывается в этот рабочий процесс.
Есть ли команда тестирования? Когда они участвуют или уведомлены? Проводится ли автоматическое тестирование в СНГ? Как поломки поступают обратно в систему?
Подумайте, как бы вы отобразили этот рабочий процесс на традиционную потоковую диаграмму с точками принятия решений и входными данными. Вы зафиксировали все точки касания высокого уровня, которые необходимы для адекватного описания вашего рабочего процесса?
Я думаю, что ваш первоначальный вопрос пытается сравнить, но я не уверен, с какими аспектами вы пытаетесь сравнить. Непрерывная интеграция имеет решающие точки, как и другие модели SDLC, но они могут находиться в разных точках процесса.
источник
Я использую термин «автоматизация разработки», чтобы охватить все действия по автоматической сборке, созданию документации, тестированию, измерению производительности и развертыванию.
Следовательно, «сервер автоматизации разработки» имеет аналогичное, но несколько более широкое назначение, чем сервер непрерывной интеграции.
Я предпочитаю использовать сценарии автоматизации разработки, управляемые перехватчиками после фиксации, которые позволяют автоматизировать как частные ветви, так и центральную магистраль разработки, не требуя дополнительной настройки на сервере CI. (Это исключает использование большинства готовых графических интерфейсов CI-серверов, которые мне известны).
Сценарий post-commit определяет, какие действия по автоматизации нужно запускать, основываясь на содержимом самой ветви; либо путем чтения файла конфигурации после фиксации в фиксированном месте в ветви, либо путем обнаружения определенного слова (я использую / auto /) в качестве компонента пути к ветви в хранилище (с помощью Svn)).
(Это легче настроить с помощью Svn, чем Hg).
Такой подход позволяет команде разработчиков более гибко подходить к организации своего рабочего процесса, позволяя CI поддерживать разработку в филиалах с минимальными (близкими к нулю) административными издержками.
источник
Есть хорошая серия постов на asp.net есть полезная непрерывной интеграции, которая может оказаться полезной, она охватывает довольно много основ и рабочих процессов, которые соответствуют тому, как вы выглядите после этого.
На вашей диаграмме не упоминается работа, выполненная сервером CI (модульное тестирование, покрытие кода и другие метрики, интеграционное тестирование или ночные сборки), но я предполагаю, что все это рассматривается на этапе «Сервер непрерывной интеграции». Я не понимаю, почему блок CI будет возвращаться в центральное хранилище? Очевидно, что он должен получить код, но зачем ему когда-либо отправлять его обратно?
CI - это одна из тех практик, которые рекомендуются различными дисциплинами, она не уникальна для схватки (или XP), но на самом деле я бы сказал, что ее преимущества доступны для любого потока, даже для негибкого, такого как водопад (может быть, влажного-подвижного?) , Для меня ключевым преимуществом является тесная обратная связь, вы довольно быстро узнаете, работает ли только что зафиксированный вами код с остальной частью кода. Если вы работаете в спринте и у вас есть ежедневные ожидания, то возможность ссылаться на статус или показатели за последние ночи на сервере CI, безусловно, является плюсом и помогает сосредоточиться на людях. Если владелец вашего продукта может видеть состояние сборки - большой монитор в общей области, показывающий состояние ваших проектов сборки - тогда вы действительно ужесточили этот цикл обратной связи. Если ваша команда разработчиков выполняет коммиты чаще (чаще, чем раз в день, а в идеале, чаще, чем раз в час), то вероятность того, что вы столкнетесь с проблемой интеграции, решение которой занимает много времени, уменьшится, но если они это сделают, все, и вы можете принять любые необходимые меры, например, все останавливаются, чтобы разобраться со сломанной сборкой. На практике вы, скорее всего, не будете сталкиваться со многими неудачными сборками, которые потребуют более нескольких минут, чтобы выяснить, часто ли вы интегрируетесь.
В зависимости от ваших ресурсов / сети вы можете рассмотреть возможность добавления различных конечных серверов. У нас есть сборка CI, которая запускается фиксацией в репозитории и предполагает, что она собирает и проходит все свои тесты, а затем развертывается на сервере разработки, поэтому разработчики могут убедиться, что он работает хорошо (вы можете включить тестирование селеном или другим пользовательским интерфейсом здесь? ). Однако не каждый коммит является стабильной сборкой, поэтому для запуска сборки на промежуточном сервере мы должны пометить ревизию (мы используем Mercurial), которую мы хотим собрать и развернуть, опять же, все это автоматизировано и запускается просто путем фиксации с определенным тег. Перейти на производство - это ручной процесс; вы можете оставить это так же просто, как заставить сборку, чтобы узнать, какую ревизию / сборку вы хотите использовать, но если вам нужно пометить ревизию соответствующим образом, то сервер CI может проверить правильную версию и сделать все необходимое. Вы можете использовать MS Deploy для синхронизации изменений на производственных серверах или для их упаковки и помещения zip-архива куда-нибудь, чтобы администратор мог развернуть его вручную ... это зависит от того, насколько вам это удобно.
Помимо повышения версии вы также должны подумать о том, как справиться с ошибкой, и отказаться от версии. Надеюсь, этого не произойдет, но в ваши серверы могут быть внесены некоторые изменения, которые означают, что то, что работает в UAT, не работает на производстве, поэтому вы выпускаете одобренную версию, а она терпит неудачу ... вы всегда можете использовать подход, который вы определили исправить ошибку, добавить некоторый код, зафиксировать, протестировать, развернуть в производство, чтобы исправить это ... или вы можете обернуть некоторые дополнительные тесты вокруг вашего автоматизированного выпуска в производство, и если они не пройдут, тогда он автоматически откатится.
CruiseControl.Net использует xml для настройки сборок, TeamCity использует мастера, если вы стремитесь избежать специалистов в вашей команде, то сложность конфигураций xml может быть чем-то еще, о чем следует помнить.
источник
Во-первых, предостережение: Scrum - довольно строгая методология. Я работал в нескольких организациях, которые пытались использовать Scrum или подобные Scrum-подходы, но ни одна из них не приблизилась к использованию всей дисциплины в полном объеме. Из своего опыта я проворный энтузиаст, но (неохотно) Scrum-скептик.
Насколько я понимаю, Scrum и другие Agile методы имеют две основные цели:
Первая цель (управление рисками) достигается путем итеративной разработки; Быстро совершать ошибки и извлекать уроки, что позволяет команде выстроить понимание и интеллектуальную способность снизить риск и перейти к решению с пониженным риском с помощью «строгого» решения с низким уровнем риска, уже находящегося в пакете.
Автоматизация разработки, включая непрерывную интеграцию, является наиболее важным фактором успеха этого подхода. Обнаружение риска и усвоение уроков должны быть быстрыми, свободными от трения и свободными от социальных факторов. (Люди учатся НАМНОГО быстрее, когда это машина, которая говорит им, что они неправы, а не другой человек - эго только мешают обучению).
Как вы, вероятно, можете сказать - я также фанат разработки, основанной на тестировании. :-)
Вторая цель связана не столько с автоматизацией разработки, сколько с человеческим фактором. Реализовать его сложнее, потому что для этого требуется вступительный взнос со стороны бизнеса, который вряд ли увидит необходимость формальности.
Здесь может сыграть свою роль автоматизация разработки, так как автоматически генерируемые документация и отчеты о ходе работы могут использоваться для того, чтобы заинтересованные лица вне группы разработчиков постоянно обновлялись с прогрессом, а информационные источники, показывающие состояние сборки и прошедшие / не прошедшие тесты, могут использоваться для информирования о прогрессе. на разработке функций, помогая (надеюсь) поддержать принятие коммуникационного процесса Scrum.
Итак, в итоге:
Диаграмма, которую вы использовали для иллюстрации своего вопроса, отражает только часть процесса. Если бы вы хотели изучать Agile / Scrum и CI, я бы сказал, что важно рассмотреть более широкие социальные и человеческие аспекты процесса.
Я должен закончить, ударяя тем же барабаном, который я всегда делаю. Если вы пытаетесь реализовать гибкий процесс в реальном проекте, лучшим показателем ваших шансов на успех является уровень развернутой автоматизации; это уменьшает трение, увеличивает скорость и прокладывает путь к успеху.
источник