Ответ 1

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

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

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

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

Итак, размер имеет значение:

small task = continuous integration
big task   = frequent integration

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

Непрерывная доставка

В рамках Непрерывной Доставки в основном есть три школы:

Непрерывная доставка является естественным продолжением непрерывной интеграции

Эта школа рассматривает серию подписей "Мартин Фаулер" Аддисона-Уэсли и делает предположение, что с тех пор, как выпуск 2007 года назывался "Непрерывная интеграция", а тот, что последовал в 2011 году, назывался "Непрерывная доставка", они, вероятно, являются томом 1 + 2 той же концептуальной идеи, которая имеет отношение к непрерывному что-то.

Непрерывная доставка связана с Agile Software Development

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

Принятие во внимание первого принципа в Agile Manifesto, где термин "непрерывная доставка" фактически используется впервые:

Нашим главным приоритетом является удовлетворение потребностей клиентов путем своевременной и непрерывной поставки ценного программного обеспечения.

Эта школа утверждает, что "Непрерывная доставка" - это парадигма, охватывающая все, что требуется для автоматической проверки вашего "определения выполненного".

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

Непрерывная доставка - это синоним непрерывного развертывания.

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

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

В какую школу поступить

Ваш университет явно присоединился к первой школе и утверждает, что мы имеем в виду том 1 + 2 той же серии публикаций. Мое мнение таково, что это неправильное использование термина "непрерывная доставка".

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

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

Непрерывное развертывание

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

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

Тот факт, что Непрерывное развертывание не является чем-то интересным для всех, является также аргументом, что школа, которая утверждает, что "доставка" и "развертывание" являются синонимами, все неправильно поняла. Потому что Continuous Delivery на самом деле имеет смысл для всех, даже если вы используете встроенное программное обеспечение для устройств или выпускаете плагины с открытым исходным кодом для платформы.

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

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

Я снова верю, что ваш университет ошибся. Они принимают "Непрерывное развертывание" за "Непрерывное освобождение".

Непрерывное развертывание - это просто дисциплина постоянной возможности переносить результат процесса разработки в производственную среду, где функциональное тестирование может выполняться в полном объеме.

Непрерывная история доставки

На картинке все это оживает:

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

Ответ 2

Ни вопрос, ни ответы не соответствуют моему простому образу мышления. Я являюсь консультантом и синхронизировал эти определения с рядом команд разработчиков и разработчиков DevOps, но мне интересно, как они соотносятся с отраслью в целом:

В основном я думаю о гибкой практике непрерывной доставки как о континууме:

Не непрерывно (все вручную) 0% → 100% непрерывная доставка стоимости (все автоматизировано)

Шаги к непрерывной доставке:

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

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

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

3. Непрерывное развертывание (CD): автоматическое развертывание, когда код передает CI, по крайней мере, в тестовую среду, предпочтительно в более высокие среды, когда качество проверяется либо посредством CI, либо путем пометки более низкой среды как PASSED после ручного тестирования. То есть, тестирование может быть ручным в некоторых случаях, но продвижение в следующую среду происходит автоматически.

4. Непрерывная поставка: автоматическая публикация и выпуск системы в производство. Это компакт-диск в производство и любые другие изменения конфигурации, такие как настройка для A/B-тестирования, уведомление пользователей о новых функциях, уведомление о поддержке новой версии и заметок об изменениях и т.д.

РЕДАКТИРОВАТЬ: Я хотел бы отметить, что есть разница между концепцией "непрерывной доставки", как указано в первом принципе Agile Manifesto (http://agilemanifesto.org/principles.html) и практикой непрерывной доставки, как представляется, на что ссылается контекст вопроса. Принцип непрерывной доставки заключается в стремлении сократить отходы инвентаризации, как описано в Lean мышление (http://www.miconleansixsigma.com/8-wastes.html). Практика непрерывной доставки (CD) гибкими командами появилась за многие годы, прошедшие с момента написания Agile Manifesto в 2001 году. Эта гибкая практика напрямую затрагивает этот принцип, хотя это разные вещи и, по-видимому, их легко спутать.

Ответ 3

Я думаю, что определение амазонки прямо и понятно.

" Непрерывная доставка - это методология разработки программного обеспечения, в которой процесс выпуска автоматизирован. Каждое изменение программного обеспечения автоматически создается, проверяется и развертывается для производства. Перед окончательным толчком к производству человек, автоматическое тестирование или бизнес-правило решает, когда должен произойти последний толчок. Хотя каждое успешное изменение программного обеспечения может быть немедленно выпущено для производства с непрерывной доставкой, не все изменения должны быть немедленно выпущены.

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

Пожалуйста, ознакомьтесь с http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

Ответ 4

Atlassian опубликовал хорошее объяснение непрерывной интеграции, непрерывной доставки и непрерывного развертывания.

В двух словах:

Непрерывная интеграция - это автоматизация для создания и тестирования приложения всякий раз, когда в ветку добавляются новые коммиты.

Непрерывная доставка - это Continuous Integration + Развертывание приложения в производство "нажатием на кнопку" (выпуск для клиентов часто, но по требованию).

Непрерывное развертывание - это непрерывная доставка, но без участия человека (выпуск для клиентов продолжается).

Ответ 5

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

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

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

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

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

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

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

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

Непрерывное развертывание описывается как следующий логический шаг после непрерывной доставки: автоматически развертывать продукт в процессе производства, когда он проходит QA!

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

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

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

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

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

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

Ответ 6

Один график может заменить много слов:

Наслаждайтесь! :-)

# Я обновил правильное изображение...

Ответ 7

Разница между непрерывной интеграцией, непрерывной доставкой и непрерывным развертыванием

Ответ 8

Я думаю, что мы закончили анализ и, возможно, немного усложнили "непрерывный" набор слов. В этом контексте непрерывная автоматизация. Для других слов, прилагаемых к "непрерывному", используйте английский язык как ваш переводчик и, пожалуйста, не пытайтесь усложнять ситуацию! В "непрерывной сборке" мы автоматически создаем (записываем/компилируем/link/etc) наше приложение в нечто исполняемое для конкретной платформы/контейнера/времени выполнения/и т.д. "Непрерывная интеграция" означает, что ваша новая функциональность проверяет и выполняет как предполагалось при взаимодействии с другим объектом. Очевидно, что до того, как произойдет интеграция, должна произойти сборка, и для проверки интеграции также будет проведено тщательное тестирование. Таким образом, в "непрерывной интеграции" используется автоматизация, чтобы добавить ценность к существующему ведру функциональности таким образом, чтобы не отрицательно нарушать существующую функциональность, а интегрировать с ней хорошо, добавляя воспринимаемую ценность к целому. Интеграция подразумевает своим простым английским определением, что вещи гармонично гармонизируют, поэтому в кодовом разговоре мои добавления компилируются, ссылки, тесты и отлично работают в целом. Вы бы не назвали что-то интегрированным, если бы он не закончил конечный продукт, не так ли? В нашем контексте "Непрерывное развертывание" является синонимом "непрерывной доставки", поскольку в конце дня мы предоставили функциональность нашим клиентам. Однако, проанализировав это, я могу утверждать, что развертывание является подмножеством поставки, потому что развертывание чего-то не обязательно означает, что мы доставляем. Мы развернули код, но поскольку мы не смогли эффективно связаться с нашими заинтересованными сторонами, нам не удалось выполнить их с точки зрения бизнеса! Мы развернули войска, но мы не доставляли обещанную воду и еду в соседний город. Что, если бы я добавил термин "непрерывный переход", имел бы ли он свои заслуги? В конце концов, возможно, это лучше подходит для описания движения кода через среды, поскольку оно имеет значение "от/до" больше, чем развертывание или доставка, которые могут подразумевать одно местоположение только на бесконечность! Это то, что мы получаем, если мы не применяем здравый смысл.

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

Ответ 9

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

Непрерывная доставка: непрерывная доставка кода в среду, как только код готов к отправке. Это может быть постановка или постановка. Идея заключается в том, что продукт доставляется на базу пользователей, которая может быть QA или клиентов для проверки и проверки.

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

Непрерывное развертывание: развертывание или выпуск кода, как только он будет готов. Непрерывное развертывание требует непрерывной интеграции и непрерывной доставки, в противном случае качество кода не будет гарантировано в выпуске.

Непрерывное развертывание ~~ Непрерывная интеграция + Непрерывная доставка

Ответ 10

DevOps представляет собой комбинацию 3C - непрерывной, связи, совместной работы, что приводит к первостепенной важности в различных отраслях.

В мире устройств, подключенных к IoT, несколько функций scrum, таких как владелец продукта, веб-сайт, мобильный и QA, работают гибким образом в схватке цикла схватки, чтобы доставлять продукт конечным пользователям.

Непрерывная интеграция: Функция множественной схватки, работающая одновременно в нескольких конечных точках

Непрерывная доставка:. При интеграции и развертывании доставка продукта нескольким клиентам должна обрабатываться одновременно.

Непрерывное развертывание: несколько продуктов, развернутых для нескольких клиентов на нескольких платформах.

Посмотрите, как узнать, как DevOps разрешает мир, подключенный к IoT: https://youtu.be/nAfZt2t4HqA

Ответ 11

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

• Автоматизированный (построение чеков и юнит-тестов)

Непрерывная доставка

• Непрерывная интеграция
• Автоматизированный (развертывание в тестовой среде + нагрузочное тестирование + интеграционный тест)
• Ручной (развертывание в производство)

Непрерывное развертывание

• Непрерывная доставка, но автоматизированная (развертывание в производство)

CI/CD - это путешествие. Не пункт назначения.

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

Сноска:

Практика непрерывной интеграции и непрерывной доставки на AWS