Яка різниця між цими трьома термінами? Мій університет пропонує такі визначення:

Безперервна інтеграція в основному означає лише те, що робочі копії розробника синхронізуються із спільним основним рядком кілька разів на день.

Безперервна доставка описується як логічна еволюція безперервної інтеграції: Завжди зумійте поставити продукт у виробництво!

Безперервне розгортання описується як наступний логічний крок після безперервної доставки: Автоматично розгортайте продукт у виробництво кожного разу, коли він пройде QA!

Вони також містять попередження: Іноді термін "Безперервне розгортання" також використовується, якщо ви можете постійно розгортатися в тестовій системі.

Все це залишає мене розгубленим. Будемо вдячні за будь-яке пояснення, яке є дещо детальнішим (або йде з прикладом)!

Постійна інтеграція

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

Ви можете стверджувати, що це лише стратегія розгалуження у вашій системі управління версіями.

Це пов'язано з розміром завдань, які ви покладаєте на розробника; Якщо завдання, за оцінками, займає 4-5 людських днів, то розробник не буде спонукати доставляти що-небудь протягом наступних 4-5 днів, оскільки він нічого не зробив - поки що.

Отже, розмір має значення:

small task = continuous integration
big task   = frequent integration

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

Постійна доставка

В основному три школи в рамках постійної доставки:

Безперервна доставка є природним продовженням постійної інтеграції

Ця школа розглядає серію підписів Аддісона-Уеслі "Мартін Фаулер" і робить припущення, що з моменту випуску 2007 року вона називалася "Безперервна інтеграція", а наступна в 2011 році називалася "Безперервна доставка", вони, ймовірно, томи 1 + 2 тієї ж концептуальної ідеї, яка має відношення до постійного чогось .

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

У цій школі виникає ідея, що безперервна доставка - це спроможність підтримувати принципи у рухливому русі, не лише як концептуальна ідея чи лист намірів, а реально - у реальному житті.

Зняття першого принципу в маніфесті "Agile", де термін "безперервна доставка" фактично використовується вперше:

Наш найвищий пріоритет - задоволення замовника шляхом ранньої та постійної доставки цінного програмного забезпечення.

Ця школа стверджує, що "Безперервна доставка" - це парадигма, яка охоплює все необхідне для впровадження автоматизованої перевірки вашого "визначення готового" .

Ця школа приймає, що "Безперервна доставка" та гучне слово або мегатренд "DevOps" є перевернутими сторонами однієї монети, у тому сенсі, що вони обидва намагаються прийняти чи інкапсулювати цю нову парадигму чи підхід, а не просто техніку.

Безперервна доставка є синонімом постійного розгортання

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

Коли щось готове до рук розробників, воно негайно доставляється кінцевим споживачам, що в більшості випадків означатиме, що його слід розмістити у виробничому середовищі. Отже, "Розгортання" та "Постачання" означають те саме.

До якої школи вступити

Ваш університет чітко приєднався до першої школи і стверджує, що ми маємо на увазі томи 1 + 2 тієї ж серії публікацій. На мою думку, це неправильне використання терміну безперервної доставки.

Я особисто виступаю за розуміння того, що безперервна доставка пов'язана з реалізацією реальної підтримки ідей та концепцій, заявлених спритним рухом. Тож я приєднався до школи, яка каже, що термін охоплює цілу парадигму - як "DevOps".

Школа, яка використовує доставку як синонім розгортання, в основному виступає у виробників інструментів, які створюють консолі розгортання, намагаючись отримати трохи галасу від більш поширеного використання терміна " Постійна доставка" .

Безперервне розгортання

Зосередженість на безперервній розгортанні є найбільш актуальною в областях, де доступ кінцевого користувача до оновлень програмного забезпечення покладається на оновлення деякого централізованого джерела для цієї інформації і де це централізоване джерело не завжди легко оновити, оскільки воно монолітне або має (занадто) високу узгодженість за природою (веб, SOA, бази даних тощо).

Для багатьох доменів, які виробляють програмне забезпечення, де немає централізованого джерела інформації (пристрої, споживчі товари, клієнтські установки тощо) або де централізоване джерело інформації легко оновити (додатки зберігають системи управління артефактами, сховища з відкритим кодом тощо). ), майже не існує галасувань щодо терміну безперервного розгортання. Вони просто розгортаються; це не велика річ - це не біль, що вимагає особливої ​​уваги.

Те, що безперервне розгортання не є цікавим для всіх, також є аргументом того, що школа, яка стверджує, що "доставка" та "розгортання" є синонімами, все помилилася. Оскільки безперервна доставка насправді має абсолютно хороший сенс для всіх - навіть якщо ви вбудовуєте програмне забезпечення в пристрої або випускаєте плагіни з відкритим кодом для рамки.

Визначення вашого університету, що безперервне розгортання є природним наступним кроком безперервної доставки, припускає, що кожна доставка, яка є QA'ed, повинна негайно ставати доступною для кінцевих споживачів, ближче до визначення, яке моє плем'я використовує для опису терміна "Безперервне Реліз ", що, в свою чергу, - це ще одна концепція, яка також не має сенсу для всіх.

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

Знову я вірю, що ваш університет помилився. Вони помиляються "Безперервне розгортання" у "Постійному випуску".

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

Історія безперервної доставки

На знімку все оживе:

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

Ні питання, ні відповіді справді не підходять до мого простого способу його думати. Я консультант і синхронізував ці визначення з низкою команд Dev та людей DevOps, але мені цікаво, як це відповідає галузі в цілому:

В основному я думаю про гнучку практику безперервної доставки, як континуум:

Не безперервна (все вручну) 0% ----> 100% Постійна доставка вартості (все автоматизовано)

Кроки до безперервної доставки:

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

1. Безперервна збірка : автоматизована збірка при кожному заїзді, що є першим кроком, але нічого не робить для підтвердження функціональної інтеграції нового коду.

2. Безперервна інтеграція (CI): автоматизована побудова та виконання принаймні одиничних тестів для підтвердження інтеграції нового коду з існуючим кодом, але бажано тестів інтеграції (від кінця до кінця).

3. Безперервне розгортання (CD): автоматичне розгортання, коли код передає CI принаймні у тестове середовище, бажано, у більш високі середовища, коли якість доведена або через CI, або шляхом позначення нижчого середовища як PASSED після ручного тестування. IE, тестування може бути ручним у деяких випадках, але просування до наступного середовища є автоматичним.

4. Безперервна доставка: автоматизована публікація та випуск системи у виробництво. Це компакт-диск на виробництві, а також будь-які інші зміни конфігурації, такі як налаштування для тестування A / B, повідомлення користувачам про нові функції, повідомлення про підтримку нової версії та нотатки про зміни тощо.

EDIT: Я хотів би зазначити, що існує різниця між поняттям "безперервної доставки", на яке посилається в першому принципі "Швидкого маніфесту" ( http://agilemanifesto.org/principles.html ), і практикою безперервної доставки, як здається, на яку посилається контекст питання. Принцип безперервної доставки полягає у прагненні зменшити відходи інвентаризації, як описано в «Художньому мисленні» ( http://www.miconleansixsigma.com/8-wastes.html ). Практика безперервної доставки (компакт-диск) спритними командами з'явилася за багато років з моменту написання Agile Manifesto в 2001 році. Ця спритна практика безпосередньо стосується принципу, хоча вони різні речі і, очевидно, легко плутаються.

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

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

Постійна інтеграція - це практика розробки програмного забезпечення, де члени команди використовують систему управління версіями та часто інтегрують свою роботу в одне і те ж місце, наприклад, в головну гілку. Кожна зміна будується та перевіряється тестами та іншими верифікаціями, щоб виявити будь-які помилки інтеграції якнайшвидше. Постійна інтеграція орієнтована на автоматичне складання та тестування коду порівняно з постійною доставкою, яка автоматизує весь процес випуску програмного забезпечення аж до виробництва ".

Перевірте http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

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

Коротко:

Безперервна інтеграція - це автоматизація для складання та тестування додатків, коли нові комісії висуваються у відділення.

Безперервна доставка - це безперервна інтеграція + Розгортання додатків у виробництві "натисканням на кнопку" (Випуск клієнтам часто, але за потребою).

Безперервне впровадження - це безперервна доставка, але без людського втручання (Випуск клієнтам триває).

Безперервна інтеграція в основному означає лише те, що робочі копії розробника синхронізуються із спільним основним рядком кілька разів на день.

Або більше, ніж кілька разів на день. В основному, як правило, виконується будь-яке окреме завдання, в основному. Розглянемо для прикладу команду розробників, що працюють над єдиним бізнес-додатком. У багатьох середовищах може статися таке:

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

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

В основному загальна ідея полягає в тому, що інтегрувати невелику зміну в невелику кількість роботи. Інтеграція великої зміни - це непропорційно великий обсяг роботи. Сукупність інтеграційних робіт є меншою, якщо вона виконується постійними невеликими кроками. Це дозволяє розробникам витрачати більше часу на роботу над видимими для бізнесу функціями, а не над процесами розробки.

Безперервна доставка описується як логічна еволюція безперервної інтеграції: Завжди зумійте поставити продукт у виробництво!

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

Чим менше робота по стабілізації, яку потрібно виконати (що, знову ж таки, є процесом розробки та слід усунути), тим частіше цю кодову базу можна перенести в будь-яке середовище. У багатьох компаніях розгортання може бути досить виснажливим процесом. Навіть тижневу операцію «на руках» на палубі. Це дорого і не дає ніякої цінності для бізнесу. Використовуючи чіткі визначення робочих позицій, ефективне автоматизоване тестування та постійну інтеграцію, команда може мати можливість автоматизувати доставку бази даних коду до будь-якого середовища.

Безперервне розгортання описується як наступний логічний крок після безперервної доставки: Автоматично розгортайте продукт у виробництво кожного разу, коли він пройде QA!

Ви рідко бачите, що це відбувається в діловому середовищі, і це дуже радість, коли з ним стикаються. Якщо кодову базу можна автоматично перевірити і автоматично розгорнути в будь-якому даному середовищі, то, ну, виробництво - це середовище, як і будь-яке інше. Отже, якщо команда розрослася до цього моменту, то потенціал має значну цінність для бізнесу, будучи завжди в змозі розгорнути оновлення для виробництва.

Виправлення дефектів надсилаються клієнтам швидше, нові функції виходять на ринок швидше, нові ідеї тестуються проти ринку з меншими кроками, щоб дозволити перенаправлення пріоритетів тощо.

Наприклад, скажімо, компанія має велику ідею щодо нової функції свого продукту чи послуги на базі програмного забезпечення. Вони провели деякі дослідження, знають ринок, і вважають, що ця ідея призведе до нової сильної лінії доходу. Тепер розглянемо два варіанти надання цієї функції:

1. Проведіть місяці, розробляючи всю справу в разовій галузі. Проведіть тижні, інтегруючи його назад в основну кодову базу. Проведіть дні, тестуючи його. Проведіть день, розгорнувши його. І лише тоді починайте відстежувати фактичний дохід у виробничій системі.
2. Реалізуйте невеликі частини функції, по одній. Кожного тижня випускайте новий фрагмент. Щотижня отримуйте більше даних про фактичний дохід.

У першому випадку, якщо ця функція не має бажаного ефекту від ринку, то багато грошей витрачається на те, що клієнти насправді не хочуть. У другому сценарії той факт, що клієнти не хочуть, визначається значно, набагато раніше, а решта роботи є пріоритетною.

Зрештою, ці "безперервні речі" - це все, що стосується вилучення процесу розвитку накладних витрат. Якщо лінія прибутку компанії - це певна послуга, то в ідеалі всі її витрати повинні перейти на цю пропозицію. Накладні витрати процесу розробки (злиття коду, повторне тестування тих самих функцій після злиття, завдання вручну розгортання тощо) насправді не сприяють цінності послуги, тому ці концепції прагнуть зняти ці витрати з процесу.

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

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

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

Різниця між постійною інтеграцією, безперервною доставкою та безперервним розгортанням

Я думаю, що ми закінчилися з аналізом і, можливо, трохи ускладнимо «безперервний» набір слів. У цьому контексті безперервне означає автоматизацію. Для інших слів, що додаються до "постійно", використовуйте англійську мову в якості посібника з перекладу, і, будь ласка, не намагайтеся ускладнювати речі! У "безперервній збірці" ми автоматично будуємо (пишемо / компілюємо / посилаємо / тощо) наше додаток у те, що виконується для певної платформи / контейнера / часу виконання / тощо. "Безперервна інтеграція" означає, що ваша нова функціональність перевіряється та працює, як було передбачено, під час взаємодії з іншим об'єктом. Очевидно, що перед тим, як відбудеться інтеграція, збірка повинна відбутися, а також для перевірки інтеграції буде використано ретельне тестування. Отже, в "безперервній інтеграції" можна використовувати автоматизацію для додавання вартості наявному пакету функціональних можливостей таким чином, що не негативно порушує існуючий функціонал, а краще інтегрується з ним, додаючи сприймане значення до цілого. Інтеграція передбачає, за своїм простою англійською дефініцією, що речі гармонійно змінюються, так що в коді-розмові моє додавання компілює, посилається, тестується і ідеально працює в цілому. Ви б не закликали щось інтегроване, якби не вийшов кінцевий продукт, чи не так ?! У нашому контексті "Безперервне розгортання" є синонімом "безперервної доставки", оскільки наприкінці дня ми надали функціональні можливості для наших клієнтів. Однак, проаналізувавши це, я можу стверджувати, що розгортання - це підмножина доставки, оскільки розгортання чогось не обов'язково означає, що ми його доставили. Ми розгорнули код, але тому що у нас немає t Ефективно донесли до наших зацікавлених сторін, ми не змогли досягти з точки зору бізнесу! Ми дислокували війська, але ми не доставили обіцяну воду та їжу в сусіднє місто. Що, якби я додавав термін "безперервний перехід", це мало б свою заслугу? Зрештою, можливо, краще підходити для опису руху коду через середовища, оскільки він має конотацію "від / до" більше, ніж розгортання чи доставку, що може означати лише одне місце розташування, на вічність! Це ми отримуємо, якщо не застосовуємо здоровий глузд. чи мала б це своя заслуга? Зрештою, можливо, краще підходити для опису руху коду через середовища, оскільки він має конотацію "від / до" більше, ніж розгортання чи доставку, що може означати лише одне місце розташування, на вічність! Це ми отримуємо, якщо не застосовуємо здоровий глузд. чи мала б це своя заслуга? Зрештою, можливо, краще підходити для опису руху коду через середовища, оскільки він має конотацію "від / до" більше, ніж розгортання чи доставку, що може означати лише одне місце розташування, на вічність! Це ми отримуємо, якщо не застосовуємо здоровий глузд.

На закінчення, це прості речі для опису (робити це трохи більше ... складніше!), Просто використовуйте здоровий глузд, англійську мову і вам буде добре.

Безперервна інтеграція: Практика постійно об'єднувати роботу з розробки з основною галуззю, щоб код був перевірений якомога частіше, щоб завчасно назвати проблеми.

Безперервна доставка: безперервна доставка коду до середовища, коли код буде готовий до доставки. Це може бути інсценізація чи виробництво. Ідея полягає в тому, що продукт поставляється на базу користувачів, яка може бути клієнтами або замовниками для огляду та огляду.

Тестовий підрозділ під час фази безперервної інтеграції не може виявити всі помилки та логіку бізнесу, особливо проблеми дизайну, тому нам потрібен QA або постановочне середовище для тестування.

Безперервне розгортання: розгортання або випуск коду, як тільки він буде готовий. Безперервне розгортання вимагає постійної інтеграції та постійної доставки, інакше якість коду не буде гарантією у випуску.

Безперервне розгортання ~~ Постійна інтеграція + Постійна доставка

Постійна інтеграція

• Автоматизовано (побудова реєстрації + одиничне випробування)

Постійна доставка

• Постійна інтеграція
• Автоматизовано (розгортання до тестового середовища + тестування навантаження + тест інтеграції)
• Посібник (розгортання до виробництва)

Безперервне розгортання

• Постійна доставка, але автоматизована (розгортання до виробництва)

CI / CD - це подорож. Не місце призначення.

Ці етапи є пропозиціями. Ви можете адаптувати етапи відповідно до потреб вашого бізнесу. Деякі етапи можна повторити для декількох типів тестування, безпеки та продуктивності. Залежно від складності вашого проекту та структури вашої команди, деякі етапи можна повторити кілька разів на різних рівнях. Наприклад, кінцевий продукт однієї команди може стати залежністю в проекті наступної команди. Це означає, що кінцевий продукт першої команди згодом ставиться як артефакт у проекті наступної команди.

Зноска:

Практикуючи постійну інтеграцію та постійну доставку на AWS

Джерело: https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/

Що таке безперервна інтеграція Безперервна інтеграція являє собою процес або практика розробки автоматизованої зборки і автоматизовані випробування тобто розробник зобов'язаний здійснити його код кілька разів в загальному сховищі , в якому кожна інтеграції перевіряються з допомогою автоматизованої збірки і тестування.

Якщо збірка не працює / успіх, про це повідомляється розробнику, і він може вжити відповідних дій.

Що таке безперервна доставка Безперервна доставка - це практика, коли ми зберігаємо код, який можна розгортати в будь-якій точці, яка пройшла весь тест і має всю необхідну конфігурацію для підштовхування коду до виробництва, але ще не розгорнута.

Що таке безперервна розгортання За допомогою CI ми створили побудову для нашої програми та готові підштовхнути до виробництва. На цьому кроці наша збірка готова і за допомогою CD ми можемо розгорнути наш додаток безпосередньо в середовищі QA, і якщо все піде добре, ми можемо розгорнути таку ж збірку до виробництва.

Таким чином, безперервне розгортання є на крок далі, ніж безперервна доставка. З цією практикою кожна зміна, яка проходить всі етапи вашої виробничої трубопроводу, передається вашим клієнтам.

Безперервне розгортання - це комбінація управління конфігурацією та контейнерізація.

Управління конфігурацією: CM - все, що стосується підтримки конфігурації сервера, сумісної з вимогами програми.

Контейнеризація : Контейнерізація - це набір платних платежів, які підтримуватимуть узгодженість середовища.

Джерело зображення: https://www.atlassian.com/

DevOps являє собою поєднання 3C - х - безперервної , комунікації , спільної роботи і це призведе до прайм фокуса в різних галузях промисловості.

У світі пристроїв, підключених до IoT, декілька функцій scrum, таких як власник продукту, веб, мобільні пристрої та QA, що працюють спритно, в циклі scrum of scrum, щоб доставити продукт кінцевому замовнику.

Безперервна інтеграція: Кілька scrum-функцій працюють одночасно в декількох кінцевих точках

Безперервна доставка: За допомогою інтеграції та розгортання доставка товару для кількох клієнтів одночасно обробляється.

Безперервне розгортання: кілька продуктів, розміщених для декількох клієнтів на декількох платформах.

Слідкуйте за цим, щоб дізнатися, як DevOps дозволяє IoT-зв’язаний світ: https://youtu.be/nAfZt2t4HqA

З того, що я дізнався з Алексом Коуаном під час безперервної доставки та розробки , CI та компакт-диск є частиною продуктового конвеєра, який складається з часу, коли він переходить від спостережень до випущеного продукту.

Від спостережень до дизайну мета - отримати якісні перевірені ідеї. Ця частина процесу вважається безперервним дизайном .

Що станеться після того, коли ми переходимо від Кодексу і надалі, це вважається можливістю безперервної доставки , мета якої - реалізувати ідеї та випускати клієнту дуже швидко (ви можете прочитати книгу Джиз Хембла Безперервна доставка: Надійне випуск програмного забезпечення за допомогою збірки, тестування, та автоматизація розгортання для більш детальної інформації). Наступний конвеєр пояснює, з яких етапів складається безперервна інтеграція (CI) та безперервна доставка (CD).

Безперервна інтеграція , як пояснює Маттіас Петтер Йохансон ,

це коли команда програмного забезпечення має звичку робити кілька злиттів на день, і у них є автоматизована система верифікації для перевірки цих об'єднань на наявність проблем.

(ви можете переглянути наступні два відео для отримання більш детального огляду за допомогою CircleCI - Початок роботи з CircleCI - Безперервна інтеграція P2 та Запуск CircleCI за запитом на витягнення ).

Можна вказати конвеєр CI / CD таким чином, що йде від Нового коду до випущеного продукту.

Перші три кроки стосуються тестів, що розширюють межу тестуваності.

Безперервне розгортання , з іншого боку, полягає в автоматичному опрацюванні Розгортання. Таким чином, будь-який код коду, який проходить етап автоматизованого тестування, автоматично випускається у виробництво.

Примітка . Це не обов'язково має виглядати ваші трубопроводи, але вони можуть слугувати орієнтиром.