Времето няма бряг… и ни влече. Така продължава песничката, от която е инспирирано заглавието. По този начин стоят нещата обаче не само за таралежите, но и за програмистите. Времето все не стига, продуктът все така не е достатъчно завършен. Всичко става все по-сложно, сроковете минават и заминават…
И така се роди аджайл светът. Вече имаме съвсем ново отношение към компютърните проекти. Те не са нещо, което се създава, стига до хората. После минава година и идва новата версия, просто вече няма как нещата да се случват по същия начин. Проектите са нещо като живо същество, което в началото се създава като доста несъвършено от гледна точка на това дали се справя с предизвикателствата на живота бебе. Наричат го и MVP, minimum viable product, продукт, който дава само най-най-основните функционалности, така че да може да се провери дали изобщо има някакъв смисъл да му се добавят следващите.
Е, следващите стъпки със сигурност се очаква да бъдат по-изпипани. Най-неочаквано обаче, много често проблемът се появява именно на този етап. Защото имаме работещ проект, програмистите добавят нещо и… счупват друго.
Начало по начало
Всичко това доведе до днешната рамка, в която до голяма степен се случват нещата при наистина огромна част от по-мащабните уеб проекти. Днес всички малко или повече всички следват процес, наречен „аджайл“ (Agilе, може би най-точният превод на термина е „гъвкав“). Това е концепция с прелюбопитна история и още по-интересни рамки за приложение, която със сигурност скоро ще ви представим по-подробно.
Но, от гледна точка на днешната ни тема, важната част е следната. Екипът работи активно и през определени интервали проектът се обновява. „Деплойва“ се, както вече се е наложило да казваме и на български, новата му версия се появява в мрежата. Това се случва достатъчно често, обикновено веднъж на 2-4 седмици. Така постепенно се добавят нови функционалности и се изчистват бъговете, които несъмнено са част от процеса, когато става дума за все по-сложни и комплексни софтуерни решения.
Как обаче е възможно да се случва това? Как толкова често се появява една изцяло нова версия на даден продукт, която не е имала достатъчно време, за да бъде тествана от всички възможни страни? И как междувременно потребителите не страдат от липсата на сайта, който са решили да отворят?
Отговорът на всички тези въпроси е именно днешният ни герой, концепцията „непрекъсната интеграция / непрекъсната доставка“, “Continuous Integration / Continuous Deployment“ или просто CI/CD.
CD си ти
Не, компактдисковете, които също се криеха зад тази абревиатура, отдавна не са сред нас като активна технология. За разлика от чудесната комбина CI/CD.
Накратко, това е концепция, колекция от принципи и комбинация от технологии, които позволяват максимално безрисково на сравнително кратък период от време да се появява нова версия на даден софтуерен продукт.
Днес, както вече сме ви разказвали доста подробно в блога на ZETTAHOST.bg, почти всички уеб приложения се „доставят“, опаковани в превърналите се в стандарт докер контейнери. Отделните контейнери пък, както също е ставало дума, се събират в групи, наречени клъстери. Управляват се лесно и удобно от системите за оркестриране, в синоним за които днес се е превърнал Kubernetes.
Ще продължавам да продължавам
Е, именно те са основните свързващи звена, който проправят пътя на CI/CD. Трябва да ги допълним само и единствено с достатъчно съвършена система за постепенно деплойване. Така в нито един момент потребителят няма да остане без достъп до услугата си. И с така любимия pipeline, който на български може би бихме превели като „тръбопровод“. Само че „тръбопровод“ просто няма как да се наложи като термин, звучи направо нелепо, затова и почти без алтернатива се ползва само англоезичният термин.
Така или иначе, идеята е, че в момента, когато проектът е готов за обновяване, той се спуска „по тръбата“. Започва една по една да минава през поредица от задачи, които да изпълни, преди да е сигурно, че е готов за обновяване. Традиционно лоудерчето за това, че нещо минава през тестова фаза, се заменя със зелено „тикче“, когато даден етап е преминат или хиксче, ако нещо не е наред.
Непрекъсната доставка (CD) започва да работи там, където непрекъснатата интеграция (CI) вече си е свършила работата. CD служи за това безаварийно да достави готовия продукт от една среда в друга – от тестовата среда, в която се разработва, той да се появи в директна връзка с потребителите. От другата страна – CI е самият процес на продължаващото развитие на апликацията, работата на програмистите и останалите хора от екипа.
Надолу по тръбите
В пайплайна могат да попадат най-различни проверки. Там задължително има проверка дали проектът се „билдва“ или компилира правилно. Там са юнит тестовете, които трябва да проверят дали не сме счупили нещо на по-ниско ниво в кода. Присъстват и линтерите, за да проверят дали пък кодът ни спазва стандартите за форматиране, които са били приети от екипа.
И едва когато всички стъпчици по тръбопровода бъдат изминати, от чучурчето накрая е готов да излезе новият проект.
Цялостната система вече е дотолкова стандартизирана, че е част от работата на почти всички екипи на големи проекти. А благодарение на напредъка в начина, по който работят сървърите, не е проблем накрая всичко да стигне до потребителя, без да има период, в който услугата е недостъпна. Докато всичко нужно се случва по протежението на пайплайна, за да е сигурно, че проектът работи, гостите на сайта ви имат спокоен достъп до по-старата му версия и от определен момент, когато вече всичко е готово, тя е заменена от новия етап в развитието на продукта ви.
Количество и качество
Не на последно място, благодарение на CI/CD софтуерните екипи няма нужда да се занимават с процесите на деплойване, обновяване, те имат в максимална степен възможност да се концентрират върху кода си. Знаейки, че през определен период имат възможността да предоставят на потребителите си нови функционалности, които да стигат лесно и бързо до тях.
Разбира се, по никакъв начин всичко това не намалява важността на другата основна професия, сродна на програмирането – хората, които отговарят за тестването. Осигуряването на качество – quality assurance или QA, е попрището на онези специалисти, които отговарят за това да проверят дали наистина всичко работи както трябва, след като излезе „изпод ръцете“ на програмиста. Тяхна е задачата да тестват функционалностите, преди да се отправят надолу, по пътя на водопровода.
Вдигни очи
Обикновено те отговарят в рамките на екипа и за още нещо важно – да подготвят т.нар. regression тестове, онази част от пайплайна, която автоматично проверява дали с новите промени не се е „счупила“ някоя по-стара функционалност.
Интернет днес е приключение с толкова много лица. Софтуерната разработка е перспективна и вълнуваща професия, а в наши дни огромна част от нея се случва именно за проекти, които директно попадат в мрежата.
Чудите се как да започнете и вие? Е, тук отговорът е доста лесен. Опитайте с напълно безплатния ни и неограничен във времето хостинг. Успех!
