Побудувати автоматизацію проти автоматизації розгортання проти постійної інтеграції

Я хочу стати більш ефективним і хочу ефективно використовувати інструменти Ops.

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

Я фактично працюю з костюмами Jetbrains у своїй роботі (IntelliJ, WebStorm ...), тому я хотів продовжувати їх використовувати, і хотів використовувати TeamCity, який здавався чудовим інструментом з багатьма плагінами для постійної інтеграції.

Моя проблема полягає в тому, що я не знаю, в чому полягають відмінності між:

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

• розгортання автоматизації (TeamCity, здається, не так легко)

• безперервна інтеграція (яка, здається, є поєднанням двох вище)
• безперервна доставка (що це саме? чому вона відрізняється від постійної інтеграції?)

Чи можете ви допомогти мені зрозуміти це трохи більше?

Вікіпедія дає досить хороші підсумки більшості цих термінів. Ось мій погляд на них:

• Автоматизація побудови - це автоматизація побудови програмного забезпечення замість того, щоб вручну викликати компілятор. Це можна зробити за допомогою таких інструментів, як напр. Make or Ant .

• Автоматизація розгортання приймає вбудоване програмне забезпечення та розгортає або встановлює його в тестовій або виробничій системі.

• Безперервна інтеграція означає автоматизований процес безперервно будувати програмне забезпечення, оскільки розробники перевіряють код і запускають тестові одиниці, щоб переконатися, що код все ще працює. Наприклад, кожні 15-30 хвилин сервер може прокидатися, сканувати VCS на нові реєстрації, потім оновити та скласти проект, якщо були внесені зміни. Окрім виконання етапів компіляції, це також чудова можливість запустити автоматизовані тести одиниць та перевірити якість коду .

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

Принаймні, вам потрібно мати автоматизацію побудови, тобто якийсь сценарій збірки. Це дозволяє вам натиснути одну кнопку або задати одну команду для створення вашого проекту. Користь для цього полягає в зменшенні помилок від ручних кроків. Складні середовища складання можуть включати генерування коду (подумайте, DAO з конфігурацій , інтерфейсного коду, такого як JAXB ), компілюючи код, упаковуючи його, налаштовуючи метадані тощо. З багатьма речами вам потрібен контрольний список: чому б не зробити контрольний список ваш сценарій збирання та використовуєте інструмент для його запуску? Це зменшує помилки та забезпечує послідовність.

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

Нарешті ми маємо кроки розгортання. Ідея тут полягає в тому, щоб заощадити час та зменшити помилки при ручному розгортанні програмного забезпечення. Так само, як автоматизація побудови, існує сто способів виправити програмне забезпечення. Я особисто затримався в офісі, щоб виправити проблеми з ручним розгортанням багато разів, коли нам потрібна функціонуюча система для клієнтів, які приїдуть завтра на майданчик. Автоматизація декількох систем створює більше ризику: замість того, щоб одна система, можливо, вийшла з ладу або мала дивні помилки, тепер у нас є кількасистеми, які можуть піти не так. Однак цей ризик набагато нижчий, ніж хтось пропускає крок у контрольному списку або видає неправильну команду і псує розгортання. Якщо вам пощастило, ви можете просто відновити резервну копію БД і почати заново, якщо вам не пощастило, помилка може призвести до неправильної роботи системи. Це дефект програмного забезпечення? Чи технік не встановив конфігурацію правильно? Це потребує часу для діагностики, часу, якого у вас може бути, і часу, який не потрібно витрачати, якщо ви автоматизуєте процес.

• Безперервна інтеграція - це практика об'єднання всіх змін розробників у спільну магістраль кілька разів на день. Ця практика зараз настільки всюдисуща, що може не здатися важливим, однак традиційно команди працювали над програмним забезпеченням тижнями чи навіть місяцями у відриві. Результатом стала «Інтеграційна пекла», коли окремі потоки роботи були об’єднані разом. Безперервна інтеграція зазвичай використовується з автоматизованими побудовами спільної магістралі для раннього пошуку проблем, але її більше стосується частих комісій та робочого процесу для розробників, ніж про DevOps.

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

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

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

Рекомендую прочитати цю книгу для отримання додаткової інформації:

• Безперервна доставка: надійне випуск програмного забезпечення за допомогою автоматизації побудови, тестування та розгортання

Teamcity, як і багато інструментів збирання, - це лише центральний додаток, який дозволяє виконувати багато різних завдань. Це включає виконання таких збірок, як збірки CI, збірок повного випуску, і це дозволяє виконувати розгортання. Якщо ви використовуєте teamcity для виклику мурашника чи nant для запуску msbuild у файлі рішення, ви також можете викликати сценарії nant, які виконуватимуть розгортання. Це може зажадати трохи сценаріїв, але це не складно.

Ми використовуємо командність та бамбук для повних інтерфейсів клієнтів, баз даних та передаються в середовище INTegration. Потім ми використовуємо teamcity для повноцінних версій версій та створення сценаріїв міграції db автоматично. Вони перевіряються у SVN за допомогою командних завдань, які викликають нант-сценарії. Для розгортань, як ви здогадалися, ми використовуємо команду команд, щоб викликати нант для виконання завдань розгортання. Це добре працює, оскільки агент teamcity спілкується з сервером teamcity, і агент може існувати на одному з серверів у DMZ-місці, що допомагає переміщувати код за межі брандмауерів тощо. Отже, teamcity або бамбук - це все, що потрібно для обробки всього сценарію .