Изградња доброг CI/CD цевовода помоћу GitHub акција То више није додатак „за кад буде времена“: у модерним тимовима, то је практично захтев за брзо и поуздано распоређивање. Упркос томе, проналажење комплетног, генеричког и добро осмишљеног примера који можете прилагодити својој компанији често је много компликованије него што се чини.
У наредним редовима ћемо комбиновати класичну теорију CI/CD са примерима имплементације из стварног света користећи GitHub акције, цевоводе за вишекратну употребу, задатке, bash скрипте, ПоверСхелл ПнП модулиИмплементације на Kubernetes, Google Cloud и Kinsta, заједно са најбољим праксама за безбедност, праћење и скалабилност. Идеја је да можете узети ове делове, уклопити их у свој контекст и избећи многе типичне замке.
Зашто вам је потребан добро изграђен CI/CD цевовод
У тренутном стручном развоју, CI/CD је циркулаторни систем кодаИнтегрише промене, покреће тестове, гради артефакте и имплементира нове верзије уз минималну интервенцију. Без овог тока рада, свако имплементирање постаје споро, склоно грешкама, ручно искушење.
Континуирана интеграција (CI) се фокусира на валидацију промена Чим се отпреме у репозиторијум, покрећу се јединични тестови, линтери и статичке анализе како би се грешке што пре откриле. Што брже добијете повратне информације, пре ћете их моћи исправити и мање ће бити болна било каква регресија.
Континуирано распоређивање (CD у смислу континуираног распоређивања) или Континуирана испорука (у зависности од нивоа аутоматизације) додаје аутоматизацију дела објављивања: изградњу слика, објављивање пакета, распоређивање у тестна, припремна или производна окружења, па чак и промену саобраћаја коришћењем плаво-зелених или канариначких стратегија.
У компанијама са пуно застарелог кодаДобар цевовод је једна од најбољих полуга за модернизацију екосистема: омогућава вам да уведете тестове у застареле сервисе, аутоматизујете задатке који су се раније обављали ручно и смањите трошкове одржавања инфраструктура попут Џенкинса или Нексуса које су застареле.
Шта су GitHub акције и зашто се тако добро уклапају са CI/CD?
GitHub Actions је платформа за аутоматизацију уграђена у GitHub. Омогућава вам да дефинишете токове рада у YAML датотекама унутар самог репозиторијума. Помоћу њега можете компајлирати, тестирати, анализирати и имплементирати свој софтвер без подешавања екстерних CI сервера.
Радни ток је скуп задатака и корака што је покренуто догађајима као што су push, pull_request, schedule (CRON), workflow_dispatch (ручно) или чак акције по проблемима. Сваки задатак се извршава у покретачу (на пример, ubuntu-latest) и састоји се од корака који користе акције или команде за вишекратну употребу run.
ГитХаб нуди огромно тржиште за акције где имате готове интеграције за скоро све: Docker, Kubernetes, AWS, Azure, Google Cloud, SonarCloud, Slack, Jira, безбедносну анализу, линтере за хиљаду језика итд. Ово значајно смањује време потребно за подешавање напредних цевовода.
У поређењу са решењима као што су Џенкинс или КонкорсGitHub Actions има неколико јасних предности: то је услуга којом се управља (не управљате серверима), уско је повезана са кодом, користи модел плаћања по употреби и подржава је огромна заједница. Штавише, многи програмери су већ упознати са њом из личних пројеката, што значајно скраћује криву учења.
Основне компоненте тока рада GitHub Actions
Све почиње са YAML датотеком у .github/workflows/, на пример ci.yml o build-test-deploy.ymlИако синтакса може знатно да се прошири, основна структура је релативно једноставна.
Кључни делови YAML-а су: name (назив радног процеса), on (догађаји који га покрећу), jobs (скуп логичких задатака), и унутар сваког посла, runs-on (trkač), steps (кораци), env (глобалне променљиве) и if (услови за извршавање корака или послова).
Послови представљају блокове рада који се могу извршавати паралелно или у ланцу користећи needsУнутар сваког посла, кораци користе акције (uses:) или команде (run:Типичан пример укључује: проверу кода, инсталацију зависности, извршавање линтера, тестове и изградњу.
Тајне и променљиве окружења Њима се управља на нивоу спремишта, организације или окружења. У токовима рада, на њих се референцира са ${{ secrets.MI_SECRET }} и омогућити рад са API кључевима, токенима за имплементацију или cloud акредитивима без њиховог излагања у спремишту.
YAML такође омогућава изградњу низова за извршење са strategy.matrix, веома корисно за тестирање вашег кода на различитим верзијама Node-а, Python-а или Java-е, или чак на различитим оперативним системима без писања истог блока више пута.
Дизајнирајте модерни CI/CD цевовод користећи најбоље праксе
Здрав цевовод је обично подељен на јасне фазебрзе провере (lint, јединични тестови), изградња артефаката, објављивање (верзија, означавање, дневник промена, објављивање у спремишту артефаката) и имплементација у једном или више окружења.
Фаза континуиране интеграције треба да буде што бржа. Ово осигурава да сваки захтев за слање или повлачење добије готово тренутну повратну информацију. Уобичајена пракса је да се различите провере покрећу паралелно користећи одвојене низове или задатке, претпостављајући нешто веће трошкове у замену за смањење укупног времена чекања.
Да би се цевовод одвојио од конкретног језикаМожете користити алатку за задатке као што је Task (слично као Make, али са синтаксом која је једноставнија за коришћење). На овај начин, ток рада GitHub Actions позива само генеричке задатке (task test, task lintитд.) и сваки репозиторијум дефинише како су интерно имплементирани у зависности од тога да ли је у питању Node, Java, Python итд.
Верзирање и артефакти долазе до изражаја током фазе објављивања.Овде правите Докер слику, jar/war датотеку, npm пакет или било који други артефакт, отпремате га у одговарајући регистар (Докер регистар, Maven, npm у регистру артефаката, итд.), означавате commit-ове и генеришете GitHub издања или дневнике промена помоћу алата као што су гит-клиф или акције пуштања на слободу.
Коначно, фаза распоређивања Преместите тај артефакт у окружење за извршавање: Kubernetes (GKE), Google App Engine, Cloud Functions, сервисе на Kinsta-и, сопствене сервере преко SSH-а итд. Овде можете повезати наредне кораке, као што су функционални тестови након имплементације или Slack обавештења са детаљима о издању.
Пример: Комплетан цевовод са ESLint-ом, тестовима и имплементацијом на Kinsta-и
Веома илустративан пример је коришћење GitHub акција Да би се валидирала React апликација помоћу ESLint-а и јединичних тестова, а затим је имплементирала на Kinsta користећи њен API. Све је оркестрирано у једном CI/CD радном току.
Први део YAML-а дефинише окидач и назив цевовода. На пример, да ради на сваком push y pull_request до филијале main, па чак и заказано помоћу CRON послова (на пример, сваког дана у поноћ или сваког понедељка у 8:00 UTC) користећи догађај schedule.
Први посао у припреми може се назвати eslint и одговоран је за проверу синтаксе кода. Покреће се у ubuntu-latest и користи низ верзија Node-а (нпр. 18.x, 20.x), са корацима за проверу и конфигурисање Node-а actions/setup-node, кеширајте npm зависности, инсталирајте са npm ci и бацити npm run lint.
Други посао, testsЗависи од eslint Медианте needs: eslintтако да се покреће само ако је провера синтаксе успешна. Унутра се образац понавља: провера, инсталација зависности и извршавање npm run test на одређеној верзији Node-а.
Трећи посао, deployВезан је после оба посла коришћење needs: и користи корак са curl да позовете Kinsta API. Да бисте то урадили, API кључ и ID апликације су конфигурисани као тајне у GitHub-у (KINSTA_API_KEY y APP_ID) и изложени су на послу путем env да се направи POST захтев који покреће имплементацију.
Важно је разумети да овај посао распоређивања Кинста сматра само прихватање API-ја успехом; међутим, ако имплементација накнадно не успе интерно унутар Кинсте, ток рада на ГитХабу може и даље приказивати зелени статус. Ово треба имати на уму како би се избегло самозадовољство и како би се процес допунио праћењем након имплементације.
Напредно управљање cron-ом и заказивање радног процеса
CRON синтакса у GitHub акцијама Заснован је на UNIX формату са пет поља: минут, сат, дан у месецу, месец и дан у недељи. Свако поље може да користи звездице, опсези, листе и кораци (*, 1-5, 1,15,30, */5), што омогућава заказивање задатака одржавања, прављења резервних копија, чишћења или периодичних провера.
Нпр 0 0 * * * извршавајте ток рада сваке поноћи (UTC), док 0 8 * * 1 То ради сваког понедељка у 8:00. Ово се беспрекорно комбинује са уобичајеним окидачима push y pull_requestтако да исти YAML може да реагује и на измене кода и на заказана извршавања.
Ова могућност је идеална за задатке које нема смисла објављивати у сваком commit-у.интензивна безбедносна скенирања (нпр. са OWASP Dependency Check у Јави), ревизије зависности, провере покривености тестовима или чишћење старих артефаката у регистру.
Поновна употреба тока посла: скалирање CI/CD на стотине репозиторијума
Када ваша организација има десетине или стотине репозиторијумаКопирање и лепљење истог YAML-а свуда је рецепт за хаос. Било каква промена захтева модификовање половине GitHub Enterprise-а, што чини готово немогућим одржавање доследности и најбољих пракси.
Решење лежи у дизајнирању радних процеса који се могу поново користити централизовано у CI/CD репозиторијуму „шаблона“. Ови токови рада откривају улазе и излазе, а свака услуга дефинише само мали YAML који их позива, прослеђујући параметре као што су тип артефакта (Docker, Java библиотека, npm пакет), време извршавања имплементације (GKE, GAE, Cloud Function, итд.) или ставке задатака које треба извршити.
Уобичајени образац је одвајање три велика радна тока за вишекратну употребу: један од build-check-task (континуирана интеграција), још једна од build-release-dockerfile или друге артефакте и треће распоређивање (deploy-gke, deploy-gaeитд.), тако да свако спремиште гради свој цевовод њиховим комбиновањем.
Да би се обухватила дељена логика, могу се дефинисати и прилагођене акције. en .github/actionsНа пример, да бисте конфигурисали Gradle, Java, Node или Task, добили метаподатке о изградњи, објавили Docker слике, означили верзије у Git-у помоћу bash скрипте или послали обавештења Slack-у. Златно правило је да репозиторијуми сервиса треба да користе само токове рада који се могу поново користити, а не директно ове радње, како би компатибилност са претходним верзијама била лакша за управљање.
Брза континуирана интеграција са задацима, матрицама и статичком анализом
Током фазе изградње или провере, препоручљиво је покренути много ствари паралелно.Јединични тестови, статичка анализа (PMD, Checkstyle, SpotBugs у Јави; ESLint у JS/TS), скенирање помоћу SonarCloud-а итд. Ово одржава укупно време израде разумним чак и у великим базама кода.
Задатак (Taskfile.yml) делује као слој апстракције на одређене команде, омогућавајући CI току рада да једноставно позове task check, task test o task lintЗа Јава пројекат, ови задаци се могу делегирати Градлу помоћу JUnit-а, PMD-а, Checkstyle-а и SpotBugs-а; за Node пројекат, Jest-у, ESLint-у и безбедносним алатима као што су npm audit или слично.
GitHub Actions додаје део низа Да бисте покренули исте задатке на различитим верзијама runtime-а: на пример, тестирање Node библиотеке на 16, 18 и 20, или Python пројекта на 3.10 и 3.12. Једноставно је као декларисати низ верзија и користити га у конфигурацији посла.
Овај приступ је посебно користан у организацијама које желе да подрже више стекова. (Јава, Ноде, Типскрипт, Пајтон, итд.) без потребе за преписивањем логике цевовода за свако спремиште: Задатак се прилагођава сваком језику, а токови посла који се могу поново користити остају практично исти.
Фаза објављивања: верзирање, означавање и објављивање артефаката
Када се провере заврше, време је за изградњу артефакта који ће заправо бити распоређен.Докер слика, JAR датотека, npm пакет, шта год је прикладно. Ово укључује и језичке алате и регистре и политику верзирања организације.
Неки Јава пројекти користе додатке попут Градле Аксиона. да управља верзијама на основу Git ознака. У мешовитим контекстима (Java, Node, итд.) може бити једноставније користити прилагођену bash скрипту која израчунава следећу верзију (на пример користећи SemVer), креира ознаку, шаље је на удаљени уређај и генерише одговарајуће издање.
Алати попут git-cliff Они помажу у генерисању дневника промена На основу порука о изменама, промене се класификују по типу (функција, исправка, грешка итд.). Њихова интеграција у процес рада осигурава да свако издање долази са јасним дневником промена, без потребе да га било ко пише ручно.
Да би се објавили артефакти, комбинују се одговарајуће акције и акредитиви.Докер регистри (Докер Хаб, ГитХаб контејнерски регистар, регистар артефаката), Мејвен репозиторијуми, нпм регистри итд. Поново, акредитиви се чувају као тајне и убризгавају у послове само када је потребно.
Континуирано распоређивање у Kubernetes, GCP, Kinsta и друга окружења
Имплементација је место где CI/CD интерагује са инфраструктуром.Овде се GitHub Actions беспрекорно интегрише са скоро сваком платформом: Kubernetes, App Engine, Cloud Functions, традиционалним серверима, платформама попут Kinsta итд.
За Кубернетес (на пример у GKE) уобичајени образац То је: аутентификација помоћу Google Cloud-а (користећи званичне акције), конфигурисање kubectl Унутар контекста кластера, примените Helm манифесте или графиконе и, ако је потребно, извршите контролисано имплементирање (нпр. са Canary или плаво-зеленим) и проверите статус помоћу команди из kubectl rollout status.
У случају App Engine-а или Cloud Functions-аЦевовод гради слику или артефакт, објављује га у регистру артефаката, а затим позива команде за распоређивање. gcloud прикладно, поново користећи управљане акредитиве као што су тајне и ефемерни тркачи.
Када се имплементација врши на спољним API-јима као што су Kinsta-овиобично је довољан један корак curl или специјализована акција која шаље захтев са токеном за аутентификацију и потребним параметрима (ИД апликације, грана итд.). Посао се сматра успешним ако API исправно одговори на захтев за ново издање.
Распоређивање је скоро увек праћено обавештењем. ка Slack-у, Teams-у или другим алатима за комуникацију, наводећи која је услуга имплементирана, у ком окружењу, са којом верзијом, ко ју је покренуо и линкове ка евиденцији тока посла. У продукцији, ово такође служи за ревизију и праћење.
Контрола квалитета: безбедност, праћење и логови
Аутоматизација изградње и имплементације је одлична, али без видљивости Што се тиче онога што се дешава, цевовод може постати црна кутија. GitHub Actions нуди детаљне евиденције по извршавању, по задатку и по кораку, што вам омогућава да дијагностикујете грешке при компајлацији, тестирању или имплементацији.
За напредније потребе, интегрисане су екстерне услуге посматрања. као што су Datadog, New Relic или Splunk, који прикупљају метрике о радним токовима, временима извршавања, стопама кварова итд., помажући у откривању уских грла и давању приоритета оптимизацијама цевовода.
Паралелно, безбедност игра кључну улогу: управљање шифрованим тајнама, минималне неопходне политике приступа, преглед дозвола за акције, укључивање скенера рањивости кода и зависности (скенирање кода, скенирање тајни, OWASP, итд.) у саме токове рада.
Многи тимови такође додају тестирање након распоређивања у новоажурираном окружењу: функционални тестови од почетка до краја, провере перформанси, основни тестови дима и, ако нешто поквари, аутоматизовани механизми враћања на претходну стабилну верзију.
Управљање током рада: заштићене гране и захтеви за повлачење
Начин рада са гранама и захтевима за повлачење мора бити усклађен са CI/CD тако да све има смисла. Најчешћа ствар је заштита главне гране (main o master) и захтевају да свака промена прође кроз PR и провере цевовода.
GitHub вам омогућава да дефинишете правила заштите грана Ове политике приморавају на употребу захтева за повлачење (pull requests), блокирају директне измене (commit) и захтевају да одређене провере статуса (одређени токови рада) буду зелене пре него што се дозволи спајање. Такође могу захтевати минималне ревизије, правила одобравања итд.
Овај модел осигурава да код који стигне до продукције Прошао је људски преглед и све аутоматизоване провере процеса, драстично смањујући ризик од пропуштања озбиљних грешака или рањивости.
У компанијама са вишеструким окружењима (развој, припрема, продукција) распоређивање у продукцију је обично резервисано за спајања у главну грану, док друге гране могу покренути распоређивања у претходна окружења за интерно тестирање или демонстрације.
Посматрајући ширу слику, добро дизајниран CI/CD цевовод са GitHub акцијама То постаје окосница развоја: интегрисање промена, покретање свеобухватних тестова, изградња и објављивање артефаката, распоређивање на више cloud платформи, праћење помоћу алата за видљивост и управљање јасним правилима гранања и захтева за повлачење. Са вишекратно употребљивим токовима рада, прилагођеним акцијама, помоћним алатима као што су Task, Rease Action и Git Cliff, и робусним управљањем тајним подацима и дозволама, могуће је подржати све, од једноставних Python апликација до сложених Kubernetes архитектура, одржавајући брзину испоруке, квалитет кода и безбедност без преоптерећења тима ручним задацима.
