🥇Справочник: какво е Continuous Delivery

По-рано ние разказахме за Continuous Integration (CI). Продължаваме с Continuous Delivery. Това е набор от методи за разработка на софтуер. Той помага да се уверим, че кодът е готов за разгръщане.

/ Pixabay / bluebudgie / PL

История

Терминът continuous delivery може да бъде видян още в agile манифеста от 2001 година в началото на списъка с основни принципи: „Приоритет е решаването на проблемите на клиента чрез непрекъсната доставка на актуален софтуер.“

През 2010 година Джез Хамбъл (Jez Humble) и Дейвид Фарли (David Farley) публикуваха книга за Continuous Delivery. Според замисъла на авторите, CD допълва подхода Continuous Integration и улеснява подготовката на кода за разгръщане.

След публикуването на книгата, подходът започна да набира популярност и само за няколко години стана практически обществено приет. Според анкетата, проведена сред повече от 600 разработчици и ИТ мениджъри през 2014 година, 97% от техническите ръководители и 84% от програмистите бяха запознати с Continuous Delivery.

В момента този подход остава един от най-популярните. Според проучване от 2018 година, в което участваше общността на IT специалистите DevOps и Jenkins Community, той използва от половината от повече от хиляда анкетирани респонденти.

Как работи Continuous Delivery

Основата на CD е готовността на кода за разгръщане. За изпълнението на тази задача се използва автоматизация на процеса на подготовка на софтуера за релиз. Той трябва да бъде стандартен за различни разработки, което ще помогне за по-бързо откриване на слабите места и оптимизирането им. Например, ускоряване на тестването.

Примерният процес на Continuous Delivery изглежда по следния начин:

Ако за автоматизацията на първите два етапа отговаря подходът Continuous Integration, то за следващите два — Continuous Delivery. Стабилността на процеса се осигурява също така и чрез системи за управление на конфигурациите. Те проследяват промените в инфраструктурата, базите данни и зависимостите. Самото разгръщане може да бъде автоматизирано или да се извърши ръчно.

Към процеса се предявяват следните изисквания:

Достъпност на информацията за готовността за излизане в production среда и готовност за непосредствен релиз (CD инструментите тестват кода и дават възможност да се оценят ефектите от измененията в релиза).
Общата отговорност за крайния продукт. Продуктовият екип — мениджъри, разработчици, тестери — мислят за резултата, а не само за своята зона на отговорност (резултатът е работен релиз, който е достъпен за потребителите на продукта).

В CD обикновено се прилага ревю на кода, а за събиране на мнения от клиентите — принципът на тъмен пуск. Новата функция първо се пуска за малък сегмент от потребителите — техният опит при взаимодействие с продукта помага за откриването на недостатъци и бъгове, които не са забелязани при вътрешното тестване.

Каква е ползата от

Непрекъснатата доставка улеснява внедряването на кода, което положително влияе на производителността и намалява вероятността от емоционално изгаряне на служителите. В крайна сметка това намалява и общите разходи за разработка. Например, CD помогна на един от екипите на HP да намали такива разходи с 40%.

Освен това — според изследване от 2016 г. (страница 28 документ) — компаниите, внедрили CD, решават проблемите с ИБ с 50% по-бързо, в сравнение с тези, които не използват подхода. До известна степен подобна разлика може да се обясни с работата на инструментите за автоматизация на процесите.

Още едно предимство — ускоряване на пускането на релизи. Във финланска компания за разработка, непрекъснатата доставка помогна да увеличи скоростта на изграждане на кода с 25%.

Потенциални сложности

Първият и основен проблем е необходимостта от преструктуриране на познатите процеси. За да се покаже ползата от новия подход, трябва да се преминава към CD постепенно, започвайки не с най-трудоемките приложения.

Втората потенциална проблематика е голямото количество клонове на кода. Последствията от "разклоняването" — чести конфликти и загуба на много време. Възможно решение — подходът без клонове.

. По-специално, в някои компании основните трудности възникват с тестването — то отнема твърде много време. Резултатите от тестовете често трябва да се анализират ръчно, но възможно решение може да бъде паралелизирането на тестовете в ранните етапи на внедряване на CD.

Следва да се обучат служителите как да работят с новите инструменти — предварителното обучение ще спести усилия и време на разработчиците.

/ Flickr / h.ger1969 / CC BY-SA

Инструменти

Представяме няколко отворени инструмента за Непрекъсната доставка:

GoCD — сървър за непрекъснато доставяне на Java и JRuby on Rails. Позволява контрол на целия процес на доставка на приложението: build—test—release. Инструментът се разпространява под лиценз Apache 2.0. На официалния сайт можете да намерите ръководство за настройка.
Capistrano — фреймворк за създаване на сценарии, които автоматизират разгръщането на приложения на Ruby, Java или PHP. Capistrano е способен да изпълнява команди на отдалечена машина, свързвайки се с нея по SSH. Работи с други инструменти за непрекъсната интеграция и доставка, например CI-сървъра Integrity.
Gradle — мултиплатформен инструмент, който автоматизира целия цикъл на разработка на приложения. Gradle работи с Java, Python, C/C++, Scala и др. Има интеграция с Eclipse, IntelliJ и Jenkins.
Drone — платформа за CD на Go. Drone може да бъде разгръщан on-premise или в облака. Инструментът е изграден на базата на контейнери и използва YAML файлове за управление на тях.
Spinnaker — платформа за непрекъсната доставка на код в мултиоблачни системи. Разработена в Netflix, голяма роля в разработката на инструмента играят инженерите на Google. Инструкции за инсталиране можете да намерите на официалния сайт.