Czym jest CI/CD? Ciągła integracja i dostarczanie wyjaśnione prosto

CI/CD to sposób wydawania oprogramowania, w którym każda zmiana w kodzie jest automatycznie budowana, testowana i — jeśli przejdzie — przygotowywana do wydania albo wydawana. CI (continuous integration) oznacza, że zmiany są często scalane i za każdym razem sprawdzane automatycznymi testami. CD (continuous delivery lub deployment) oznacza, że zmiany, które przeszły, są pakowane i przekazywane do użytkowników z niewielkim albo żadnym ręcznym wysiłkiem.

Sens jest prosty: wyłapywać błędy minuty po ich popełnieniu, a nie tygodnie później, kiedy zauważy je klient.

Dlaczego CI/CD ma znaczenie, gdy budujesz z AI

Kreatory AI wprowadzają zmiany w kodzie bardzo szybko. Jeden prompt może dotknąć dziesięciu plików. To świetne, dopóki zmiana na stronie płatności po cichu nie zepsuje logowania i nikt tego nie zauważy, aż użytkownik napisze do ciebie e-mail.

CI/CD jest siatką bezpieczeństwa właśnie na taką okoliczność. Zamiast ufać, że każda zmiana jest w porządku, potok przy każdym razie uruchamia te same sprawdzenia:

• Czy aplikacja nadal buduje się bez błędów?
• Czy automatyczne testy nadal przechodzą?
• Czy kod przestrzega zasad projektu (typy, formatowanie, kontrole bezpieczeństwa)?

Jeśli którekolwiek sprawdzenie zawiedzie, zmiana zostaje zatrzymana, zanim dotrze do użytkowników. Im szybciej zmienia się kod, tym cenniejsze jest sprawdzenie, które nigdy się nie męczy ani nie pomija kroku.

Codzienna analogia

Pomyśl o piekarni, która każdego ranka dostarcza chleb do sklepów.

• Bez CI/CD każdy piekarz przez tydzień sam poprawia przepis, a w piątek wieczorem wszystkie zmiany łączy się i liczy, że chleb wyrośnie. Gdy nie wyrośnie, nikt nie wie, czyja zmiana to spowodowała.
• Z CI każda mała zmiana w przepisie od razu trafia do próbnego bochenka i jest sprawdzana — smak, waga, kształt. Złą zmianę wyłapuje się tego samego dnia i wiadomo dokładnie, która to była.
• Z CD bochenki, które przeszły kontrolę, od razu trafiają do furgonetki dostawczej, zapakowane i oznaczone zawsze tak samo, zamiast ktoś pakuje pudła ręcznie o 5 rano.

Kontrola nie czyni piekarzy lepszymi. Sprawia, że ich błędy są tanie.

Jak działa potok CI/CD

Potok (pipeline) to lista kroków, które usługa CI/CD uruchamia automatycznie, gdy coś się wydarzy — zwykle gdy ktoś wysyła kod do repozytorium, np. GitHub. Typowy potok wygląda tak:

Każdy krok działa na czystej maszynie, a nie na czyimś laptopie, więc wymówka „u mnie działa” przestaje wystarczać. Jeśli krok się nie powiedzie, potok się zatrzymuje i informuje osobę, która wprowadziła zmianę.

Kroki są opisane w pliku konfiguracyjnym, który leży razem z kodem. W GitHub Actions to na przykład plik YAML w folderze .github/workflows repozytorium.

Ciągłe dostarczanie a ciągłe wdrażanie

Skrót „CD” jest niejednoznaczny i ludzie używają go w obu znaczeniach:

Ciągłe wdrażanie działa dobrze tylko wtedy, gdy testy są dobre. Jeśli twoje testy nie obejmują płatności, ciągłe wdrażanie z radością wyśle na żywo zepsutą płatność.

Przykład krok po kroku: aplikacja rezerwacji z potokiem

Załóżmy, że masz aplikację do rezerwacji w salonie, a jej kod jest w repozytorium GitHub. Prosisz kreatora AI: „dodaj 10% zniżki dla klientów, którzy przychodzą pierwszy raz.”

1. Zmiana zostaje wysłana do nowej gałęzi i otwierany jest pull request.
2. Potok startuje. Instaluje pakiety i buduje aplikację — to przechodzi.
3. Uruchamia testy. Jeden test, „stały klient płaci pełną cenę”, nie przechodzi: zniżka jest naliczana wszystkim.
4. Pull request pokazuje czerwony krzyżyk. Zmiany nie da się scalić.
5. Prosisz AI o poprawkę. Wysyła korektę; potok działa ponownie i wszystko przechodzi.
6. Zmiana zostaje scalona. Potok wdraża ją na środowisko stagingowe, gdzie testujesz próbną rezerwację.
7. Zatwierdzasz i wdrażane jest na produkcję.

Bez potoku krok 3 wydarzyłby się w portfelach twoich klientów.

Kluczowe pojęcia

Częste mylne przekonania

• „CI/CD oznacza, że moja aplikacja jest przetestowana”. Potok uruchamia tylko te testy, które masz. Jeśli testów nie ma, CI potwierdza jedynie, że aplikacja się buduje — nic więcej. Poproś AI o testy dla najważniejszych przepływów.
• „CI/CD jest tylko dla dużych firm”. Hostowane narzędzia, jak GitHub Actions, wymagają krótkiego pliku konfiguracyjnego, a małe zespoły używają ich cały czas. Wysiłek leży w testach, a nie w narzędziach.
• „Automatyczne wdrażanie oznacza, że nikt niczego nie sprawdza”. Dobre potoki dodają sprawdzenia, a nie je usuwają. Wiele zespołów zachowuje etap zatwierdzenia przez człowieka przed produkcją.
• „Jeśli potok jest zielony, aplikacja działa”. Oznacza to, że zautomatyzowane kontrole przeszły. Nadal powinieneś sam wypróbować zmianę, najlepiej w podglądzie lub na stagingu.
• „CI/CD zastępuje kopie zapasowe”. Nie zastępuje. Złe migracje bazy danych, które przejdą testy, nadal mogą uszkodzić prawdziwe dane. Zachowaj kopie zapasowe i sposób na wycofanie zmian.

O co poprosić swojego kreatora AI

• „Napisz automatyczne testy dla rejestracji, logowania i płatności i pokaż, jak je uruchomić.”
• „Skonfiguruj przepływ GitHub Actions, który instaluje zależności, buduje aplikację i uruchamia testy przy każdym pull requeście.”
• „Dodaj sprawdzanie typów i linter do potoku i spraw, by kończył się błędem przy problemach.”
• „Wyjaśnij prostym językiem, co robi każdy krok potoku.”
• „Co się dzieje, gdy wdrożenie nie uda się w połowie? Jak wycofać zmiany?”
• „Sprawdź, czy żadne sekrety nie są zapisane na sztywno w repozytorium ani wypisywane w logach potoku.”

Jeśli twoja aplikacja używa kluczy API, potok też ich potrzebuje — przechowywanych jako zaszyfrowane sekrety w narzędziu CI, nigdy w pliku konfiguracyjnym. Zobacz zmienne środowiskowe i sekrety.

CI/CD a Mythex

Mythex nie uruchamia za ciebie potoku CI, ale zaspokaja kilka z tych samych potrzeb na swój sposób:

• Punkty kontrolne. Po każdej udanej turze agenta Mythex zapisuje punkt kontrolny git, a Przywróć do tego punktu cofa projekt, jeśli zmiana poszła źle. Zobacz Czat.
• Testowanie aplikacji. Wpisz /test, a agent przeklika twój żywy podgląd jak użytkownik i zgłosi zepsute przepływy — przydatne przed każdą publikacją. Zobacz Testowanie aplikacji.
• Publikacja to świadomy krok. Zmiany najpierw pojawiają się w prywatnym podglądzie; twoja publiczna aplikacja aktualizuje się dopiero, gdy opublikujesz ponownie — bliżej ciągłego dostarczania niż ciągłego wdrażania.
• Synchronizacja z GitHub (Pro). Zsynchronizuj projekt z repozytorium GitHub, a możesz dodać własne przepływy GitHub Actions uruchamiające testy przy każdym wysłaniu kodu. Zobacz GitHub i eksport.

Listę tego, co przetestować ręcznie przed startem, znajdziesz w jak przetestować aplikację przed premierą, a o pracy z kontrolą wersji w jak używać Gita z aplikacją zbudowaną przez AI.

Pytania