Thank you for reading this post, don't forget to subscribe!

CI/CD — кон­цеп­ция, кото­рая реа­ли­зу­ет­ся как кон­вей­ер, облег­чая сли­я­ние толь­ко что зако­ми­чен­но­го кода в основ­ную кодо­вую базу. Кон­цеп­ция поз­во­ля­ет запус­кать раз­лич­ные типы тестов на каж­дом эта­пе (выпол­не­ние инте­гра­ци­он­но­го аспек­та) и завер­шать его запус­ком с раз­вер­ты­ва­ни­ем зако­ми­чен­но­го кода в фак­ти­че­ский про­дукт, кото­рый видят конеч­ные поль­зо­ва­те­ли (выпол­не­ние достав­ки).

CI/CD необ­хо­ди­мы для раз­ра­бот­ки про­грамм­но­го обес­пе­че­ния с при­ме­не­ни­ем Agile-мето­до­ло­гии, кото­рая реко­мен­ду­ет исполь­зо­вать авто­ма­ти­че­ское тести­ро­ва­ние для быст­рой налад­ки рабо­че­го про­грамм­но­го обес­пе­че­ния. Авто­ма­ти­че­ское тести­ро­ва­ние дает заин­те­ре­со­ван­ным лицам доступ к вновь создан­ным функ­ци­ям и обес­пе­чи­ва­ет быст­рую обрат­ную связь.

принципы CI/CD.

1. Пер­вый прин­цип CI/CD: сегре­га­ция ответ­ствен­но­сти заин­те­ре­со­ван­ных сторон.
2. Вто­рой прин­цип CI/CD: сни­же­ние риска.
3. Тре­тий прин­цип CI/CD: корот­кий цикл обрат­ной связи.
4. Реа­ли­за­ции сре­ды в CI/CD.
5. Инстру­мен­ты для CI/CD.

Пер­вый прин­цип CI/CD: сегре­га­ция ответ­ствен­но­сти заин­те­ре­со­ван­ных сторон
Одним из основ­ных пре­иму­ществ CI/CD явля­ет­ся свое­вре­мен­ное уча­стие раз­лич­ных заин­те­ре­со­ван­ных сто­рон в любом проекте.

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

Инже­не­ры по каче­ству (QE) отве­ча­ют за под­дер­жа­ние каче­ства про­дук­ции, про­смотр функ­ций по мере их выпол­не­ния (см. опре­де­ле­ние «Гото­во») и вво­дят сквоз­ные (E2E) функ­ции / при­е­моч­ные тесты, что­бы уста­но­вить, что кли­ент полу­чит про­дукт рабо­та­ю­щий без ошибок.

Биз­нес-ана­ли­ти­ки (BAs) и вла­дель­цы про­дук­тов (POs) несут ответ­ствен­ность за при­ем­ле­мость (напри­мер, сто­и­мость биз­не­са), что под­твер­жда­ет­ся вза­и­мо­дей­стви­ем с фак­ти­че­ски­ми поль­зо­ва­те­ля­ми и созда­ни­ем поль­зо­ва­тель­ских исто­рий. Они коор­ди­ни­ру­ют и ана­ли­зи­ру­ют резуль­та­ты при­е­моч­ных тестов для про­вер­ки рас­ска­зов поль­зо­ва­те­лей и, воз­мож­но, созда­ния новых, осно­ван­ных на отзывах.

Опе­ра­тив­ный отдел (Ops)/ DevOps-инже­не­ры несут ответ­ствен­ность за доступ­ность про­дук­та поль­зо­ва­те­лям. Рабо­тая в обла­сти CI/CD, они мас­шта­би­ру­ют кон­цеп­ции по мере необ­хо­ди­мо­сти и раз­ра­ба­ты­ва­ют логи­сти­ку кода, что­бы код от раз­ра­бот­чи­ков мог перей­ти в про­из­вод­ствен­ную сре­ду и поль­зо­ва­те­ли мог­ли полу­чать доступ.

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

Каж­дый этап кон­вей­ер­ной обра­бот­ки CI/CD созда­ет сре­ду, настро­ен­ную на то, что­бы груп­пы бра­ли ответ­ствен­ность за соот­вет­ству­ю­щую ста­дию тести­ро­ва­ния, обес­пе­чи­вая целост­ность процесса.

Вто­рой прин­цип CI/CD: сни­же­ние риска

Каж­дый этап кон­вей­ер­ной обра­бот­ки CI/CD созда­ет­ся для сни­же­ния рис­ка в опре­де­лен­ном аспек­те. Раз­ра­бот­чи­ки отве­ча­ют за логи­че­ские и пись­мен­ные тесты, что­бы сни­зить риск нару­ше­ния логи­ки. QE отве­ча­ют за целост­ность пото­ка поль­зо­ва­те­лей и запи­сы­ва­ют тесты для сни­же­ния рис­ка сло­ман­ных потоков/ исто­рий поль­зо­ва­те­лей. BAs и POs отве­ча­ют за удоб­ство исполь­зо­ва­ния и при­ни­ма­ют уча­стие в при­е­моч­ных тестах поль­зо­ва­те­лей, что­бы сни­зить риск созда­ния непри­год­ных / неже­ла­тель­ных функ­ций. Ops/ DevOps несут участ­ву­ют в обслу­жи­ва­нии CI/CD, свя­зан­ные с раз­вер­ты­ва­ни­ем опе­ра­ций (ана­лиз схе­мы данных/ мигра­ции дан­ных) и мас­шта­би­ро­ва­ние, что­бы сни­зить риск недо­ступ­но­сти продукта.

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

Тре­тий прин­цип CI/CD: корот­кий цикл обрат­ной связи

При­чи­на внед­ре­ния кон­вей­ер­ной обра­бот­ки CI/CD — исполь­зо­ва­ние машин для рабо­ты с людь­ми. Это поз­во­ля­ет сокра­тить вре­мя, затра­чи­ва­е­мое на обрат­ную связь по раз­ра­ба­ты­ва­е­мым функциям.

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

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

Реализации среды в CI/CD

Мы рас­смот­рим раз­лич­ные сре­ды реа­ли­за­ции CI/CD и то, что про­ис­хо­дит на каж­дом эта­пе, ссы­ла­ясь на реа­ли­за­цию в про­ек­тах, над кото­ры­ми я рабо­таю. Каж­дая сре­да пред­став­ле­на как ветвь репо­зи­то­рия систе­мы кон­тро­ля кода.

Раз­ра­бот­ка

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

Кон­троль качества

Про­дукт про­хо­дит про­цесс сбор­ки, а тесты модулей/ систем сно­ва запус­ка­ют­ся в сре­де с кон­фи­гу­ра­ци­я­ми про­из­вод­ства на уровне при­ло­же­ний. Код раз­вер­ты­ва­ет­ся в QA-вер­сии нашей плат­фор­мы, а тесты функ­ций запус­ка­ют­ся два раза в день. При про­хож­де­нии регрес­си­он­ных тестов код в вет­ви qa про­дви­га­ет­ся к вет­ви uat.

Про­вер­ка приемлемости

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

Тести­ро­ва­ние инте­гра­ци­он­ных систем

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

Про­из­вод­ство

Поль­зо­ва­те­ли полу­ча­ют воз­мож­ность оце­ни­вать выпу­щен­ные функции.

Инстру­мен­ты для CI/CD
Локаль­ные

GitLab CI, TeamCity, Bamboo, GoCD Jenkins, Circle CI.

Облач­ные

BitBucket Pipelines, Heroku CI, Travis, Codeship, Buddy CI, AWS CodeBuild.

Пра­ви­тель­ствен­ные

hats, Nectar.