Пускам, качвам, прилагам — същност на термините и разлики

Какво означава „пускам“, „качвам“, „прилагам“

„Пускам“ — най-общият термин, означаващ публикуване на нова версия на софтуерен продукт, функционалност или промяна. „Пуснахме обновлението“, „пуснахме поправката“, „пуснахме изданието“ — във всички случаи става въпрос за това, че промяната е станала достъпна за потребителите. Терминът предполага доста голямо действие: обикновено се пуска цялата версия, а не един файл.

„Качвам“ — по-конкретен термин, означаващ качване на файлове, данни или артефакти на сървър или в хранилище. „Качи билда на сървъра“, „качи скриптовете в базата данни“, „качи активите в CDN“. За разлика от «пускам», терминът не предполага, че каченото е станало достъпно за потребителите — файловете може да са на сървъра, но все още да не са свързани към приложението. Нюанс: «качвам» се използва и за изпращане на код в хранилище („качих в GitHub“).

„Прилагам“ — термин, означаващ прилагане на промяна върху съществуваща версия. „Приложи миграцията“, „приложи пач“, „приложи конфигурацията“. Ключовата разлика — промяната се нанася отгоре без пълна замяна. Ако «пускам» е стартиране на нова версия вместо старата, то «прилагам» е добавяне на промяна към това, което вече работи. Терминът е разпространен в контекста на бази данни (миграции) и пач издания.

Допълнителни термини от същото семантично поле: «разпространявам» (разпространявам промяната на всички сървъри в клъстера), «връщам» (връщам предишната версия), «случайно разполагам» (случайно разполагам грешната версия). Всички тези глаголи описват действия с кода като физически обект, който може да се «търкаля», «лее» и «връща назад».

Произход на сленговите термини

Терминът „пускам“ произлиза от автомобилната метафора: «изкарвам колата от гаража». Когато кодът е готов за издаване, той се «пуска» — освобождава се, прави се достъпен за потребителите. Метафората се разпространява в началото на 2000-те години с появата на continuous delivery практиките, когато изданията стават редовни, а не годишни. „Днес имаме пускане“ — означава ден на издаване.

Терминът „качвам“ има корени в ранния уеб, когато сайтовете се качваха на сървъри чрез FTP. «Качвам файлове на сървъра» — буквално прехвърляне на файлове чрез протокол, който се асоциира с «изливане» на данни. Думата се е запазила, въпреки че съвременното разполагане използва CI/CD пайплайнове, а не FTP клиенти. Интересен факт: на английски аналогът е «push» (push to server), а не «pour». Руският език е избрал друга метафора.

Терминът „прилагам“ идва от производствената среда: «поставям колело», «завивам гайка». В контекста на софтуер — прилагане на промяна към съществуваща система, както се навива резба на болт. В базите данни терминът е особено органичен: миграциите именно се «прилагат» (apply) и «връщат» (rollback). Rollback — един от малкото английски термини, който има точен български аналог «връщане».

Разлика между термините в различни контексти

В контекста на бази данни: миграциите се «прилагат», данните се «качват», версията на схемата се «пуска». Ако трябва да се добави нова колона — прилага се миграция. Ако трябва да се вмъкнат тестови данни — качва се дамп. Ако структурата на базата данни се промени изцяло — пуска се нова схема. Разликата отразява различни операции: apply, insert/load, deploy.

В контекста на DevOps: «пускам» — стартиране на пайплайн, «качвам» — качване на Docker образ в регистър, «прилагам» — прилагане на конфигурация на сървър чрез Ansible. Пример: «първо качваме образа в регистъра, после прилагаме конфига на сървъра, и чак тогава пускаме изданието». Всеки термин отговаря на отделен етап от CI/CD пайплайна.

В контекста на мобилната разработка: «качвам» — изпращане на билд до App Store Connect или Google Play Console, «пускам» — публикуване в магазина за приложения, «прилагам» — доставяне на обновление чрез механизма in-app updates. За iOS «пускам» означава преминаване през Review, за Android — rollout чрез Play Console. Времева скала: «качването» отнема минути, «пускането» — часове или дни (поради ревю).

Етапи на процеса на издаване: от комит до продукция

Етап 1: Компилиране (Build). Кодът се компилира, създава се артефакт (бинарен файл, Docker образ, APK/IPA). CI сървърът стартира компилиране след всеки комит в основния клон. Резултатът от компилирането — артефакт, готов за разполагане с уникален таг на версията (semantic versioning или commit hash). Ако компилирането се провали — целият пайплайн спира, разработчикът получава известие.

Етап 2: Тестване (Test). Стартират се unit тестове, интеграционни тестове, линтери, проверка за сигурност (SAST). Този етап не трябва да отнема повече от 10–15 минути — ако е по-дълго, разработчиците губят контекст и преминават към други задачи. Бързата обратна връзка — ключов принцип на CI/CD. Според Puppet State of DevOps 2023, екипите с бързо тестване (<10 мин) правят 3 пъти повече издания.

Етап 3: Разполагане на стейджинг (Staging Deploy). Артефактът се разполага в стейджинг среда, идентична на продукционната. На стейджинга се изпълняват E2E тестове, smoke тестове и, при необходимост, ръчно тестване от QA. Ако на стейджинга бъде открита регресия — изданието се блокира, промените се изпращат за корекция.

Етап 4: Пускане в продукция (Production Deploy). Артефактът се разполага на продукционните сървъри. В зависимост от стратегията за разполагане (rolling, blue-green, canary) пускането може да отнеме от няколко секунди до няколко часа. След пускането се стартират post-deploy тестове и мониторинг — ако метриките са нормални, изданието се счита за успешно. Автоматично връщане при превишаване на прага на грешки — стандартна практика.

Стратегии за разполагане: rolling, blue-green, canary

Rolling deploy — обновяване на сървърите един по един. Докато един сървър се обновява, останалите продължават да обслужват потребителите. След успешно обновяване на първия сървър, се обновява вторият, и така нататък. Недостатък: по време на разполагане на сървърите работят различни версии, което може да причини несъвместимост. Предимство: zero-downtime и липса на необходимост от двоен брой сървъри.

Blue-green deploy — две идентични среди: Blue (текуща версия) и Green (нова версия). След като Green е напълно готов и тестван, балансьорът превключва трафика от Blue към Green. Ако в Green бъде открит проблем — превключваме обратно към Blue. Предимство: незабавен rollback. Недостатък: необходими са два пъти повече ресурси (сървъри) за поддържане на две среди. Превключването отнема секунди.

Canary deploy — новата версия първо се разполага на малък процент сървъри (5–10%). Част от потребителите попадат на новата версия, останалите — на старата. Ако метриките в canary групата са нормални (процентът грешки не се е увеличил, латентността не се е повишила), новата версия постепенно се разпространява на всички сървъри. Google, Netflix, Spotify използват canary deploy за минимизиране на риска. Недостатък: сложност на мониторинга и анализа на метрики.

Инструменти за автоматизация на разполагането

CI/CD сървъри — Jenkins, GitLab CI, GitHub Actions, CircleCI, Bitrise (за мобилни). Избират се в зависимост от стека: Jenkins — универсален, GitLab CI — ако хранилището е в GitLab, Bitrise — за iOS/Android. Основната задача на CI/CD сървъра — автоматично изпълнение на пайплайна за компилиране, тестване и разполагане без човешка намеса.

Контейнеризация — Docker, Kubernetes. Docker създава изолирани контейнери с приложението и всички зависимости. Kubernetes управлява разполагането на контейнери в клъстер от сървъри: автоматично rolling обновяване, мащабиране, балансиране. Според CNCF Survey 2023, 96% от организациите използват контейнери в продукция, от които 67% — Kubernetes.

Infrastructure as Code — Terraform, Ansible, Pulumi. Terraform описва инфраструктурата (сървъри, мрежи, балансьори) под формата на код и управлява нейното състояние. Ansible — конфигурация на сървъри: инсталиране на софтуер, настройка на параметри. Комбинацията Terraform + Ansible осигурява напълно автоматизирана инфраструктура: Terraform изгражда сървърите, Ansible ги конфигурира. Immutable infrastructure — сървърите не се обновяват, а се заменят с нови с обновен образ.