Нови версии без изненади: автоматични проверки преди всяко внедряване

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

Цената излиза по-късно. Грешките ги откриват клиентите вместо тестовете. Зависимостите изостават с години, защото обновяването изглежда рисковано. Документацията не отговаря на кода, а на новите хора им трябват седмици, за да научат неписаните правила. Новите версии излизат рядко и с напрежение, и всяка носи риск.

Изследванията DORA описват показатели за това колко добре екип доставя софтуер. Класическите четири са колко често се внедряват нови версии, колко време минава от промяната до внедряването ѝ, какъв дял от внедряванията предизвиква проблем и колко бързо се възстановява работата след неуспешно внедряване. По-късно моделът добавя и пети показател: колко често се налагат непланирани внедрявания, за да се поправи проблем в работещата система.

Показателите описват едновременно скоростта и стабилността. Полезни са за ръководството, защото превръщат „екипът е бавен“ в конкретни въпроси за това къде се губи времето и откъде идват грешките.

Първо стилът. Автоматичното форматиране, например с Prettier, и linter-ите, които проверяват правила и типични грешки, например ESLint, се пускат при всяка промяна. За PHP има техни еквиваленти. Ревюто остава за логиката, а промените се преглеждат по-лесно.

Статичен анализ рано в процеса. Той открива грешни типове, недостижим код и грешни извиквания, докато поправката им е още евтина. Пуска се преди или паралелно с бързите тестове, за да не удължава чакането.

Тестове на няколко нива. Най-много са бързите unit тестове на отделните части, после интеграционните, които проверяват връзките между тях, и най-малко end-to-end тестовете на ключовите потоци: вход, плащане, основната поръчка или заявка. End-to-end тестовете минават в реален браузър, например с Playwright. Тъй като са по-бавни, пълният им набор често върви преди сливане или преди внедряване.

Един стандарт за API. Програмните интерфейси се описват по стандарта OpenAPI, документацията се генерира автоматично, а процесът проверява, че описанието съвпада с реалното поведение на API-то. Така всяка система, която го ползва, работи по един и същ договор.

Зависимостите като рутина. Lock файловете фиксират точните версии на зависимостите, автоматичните заявки за обновяване идват на малки порции, а проверката за известни уязвимости е част от процеса.

Едно изграждане от теста до работещата система. Изграденият образ, например Docker образ, се тества веднъж и точно той се внедрява, вместо да се изгражда наново за всяка среда. Изграждането на етапи (multi-stage build) помага образът да е по-малък и без инструменти за разработка. Конфигурацията и тайните остават отделни за всяка среда.

Автоматичните проверки намаляват грешките, но не ги нулират. Затова всяка версия минава първо през тестова среда, възможно най-близка до работещата. След внедряването кратка автоматична проверка (smoke test) и наблюдението на грешките показват проблемите, преди клиентите да ги съобщят.

Връщането към предишната версия се планира предварително. Промените в базата данни се правят на стъпки (разширяване и свиване, expand-and-contract), така че старата и новата версия да могат да работят със същите данни. Където е възможно, новата функционалност се включва постепенно или чрез превключватели (feature flags) и може да се изключи без ново внедряване.

Връщането назад не винаги е правилният ход. Ако вече има необратими операции, като изпратени плащания или съобщения, или данни в нов формат, понякога е по-безопасно бързо да се пусне поправка. Кога се връща версия и кога се поправя напред, се решава предварително, а не по време на проблема.

Основният клон в хранилището е настроен така, че да приема промени само след минали проверки и ревю.

Тайните, като ключове и пароли, не се пазят в кода. За по-малък проект е достатъчно те да са в защитените настройки на средата и на CI системата. С растежа на проекта е по-добре да са в мениджър на тайни, например HashiCorp Vault или услугата на облачния доставчик. Там се вижда кой ги използва, а смяната им може да е автоматична. Където е възможно, процесът ползва краткотрайни достъпи (например чрез OIDC) вместо постоянни ключове. Автоматична проверка следи тайни да не попаднат в кода, а изтеклите се сменят веднага.

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

Важна част са хората. Разработчиците и QA специалистите се научават да пишат и поддържат автоматичните тестове, и проверката на ключовите потоци престава да зависи от един човек. Тогава тези потоци се проверяват автоматично при всяко сливане или внедряване.

При добре настроен процес ревютата стават по-кратки и по-полезни, защото стилът и простите грешки вече са поети от автоматичните проверки.

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