Bitbucket i CI/CD

Bitbucket i CI/CD: przegląd kodu, testy i wdrożenia bez ręcznego wgrywania plików

Bitbucket to usługa firmy Atlassian do przechowywania kodu w repozytoriach Git, z pull requestami (prośbami o scalenie zmian), przeglądem kodu, ochroną gałęzi i integracją z Jirą. Wersja chmurowa, Bitbucket Cloud, ma wbudowane Bitbucket Pipelines – usługę CI/CD, która na podstawie pliku konfiguracyjnego w repozytorium automatycznie buduje, testuje i wdraża kod.

CI/CD to skrót od continuous integration oraz continuous delivery lub continuous deployment, czyli ciągłej integracji i ciągłego dostarczania lub wdrażania. Każda zmiana przechodzi tę samą zautomatyzowaną ścieżkę: od zapisania w repozytorium, przez testy, po publikację. Opisujemy tu Bitbucket, Bitbucket Pipelines i to, jak organizujemy CI/CD w projektach – także wtedy, gdy kod jest przechowywany w innym systemie.

Czym jest Bitbucket i co go wyróżnia

Bitbucket Cloud przechowuje repozytoria Git w chmurze Atlassiana. Zmiany trafiają do głównej gałęzi przez pull requesty, a reguły scalania (merge checks) pilnują jakości: wymaganej liczby akceptacji, udanych buildów dla ostatniego commita, zamkniętych zadań z przeglądu i braku prośby o poprawki. W planie Premium te warunki można wymusić, czyli zablokować scalenie, dopóki nie są spełnione. Ograniczenia gałęzi (branch restrictions) określają, kto może zapisywać lub scalać zmiany w wybranych gałęziach.

Bitbucket jest szczególnie wygodny dla zespołów pracujących w Jirze. Wystarczy umieścić klucz zadania, np. ABC-123, w nazwie gałęzi, opisie commita lub tytule pull requesta, a w Jirze przy tym zadaniu pojawią się gałęzie, commity i pull requesty, przy włączonym Pipelines także buildy i wdrożenia. Tzw. smart commits pozwalają z poziomu opisu commita dodać komentarz do zadania, zapisać czas pracy lub zmienić jego status.

CI/CD – ciągła integracja i wdrażanie w Bitbucket Pipelines

Ciągła integracja (CI) oznacza, że każda zmiana wysłana do repozytorium jest automatycznie budowana i testowana, więc błąd wychodzi na jaw zaraz po jej wprowadzeniu, a nie przy wdrożeniu. Ciągłe dostarczanie (continuous delivery) idzie dalej: zmiana, która przeszła testy, jest automatycznie przygotowywana do publikacji i trafia na produkcję po ręcznej akceptacji. Przy ciągłym wdrażaniu (continuous deployment) tej akceptacji nie ma – produkcja aktualizuje się automatycznie.

W Bitbucket Pipelines całą ścieżkę opisuje plik bitbucket-pipelines.yml w katalogu głównym repozytorium, wersjonowany razem z kodem. Kroki działają w kontenerach Docker, a konfiguracja obejmuje m.in.:

• wyzwalacze – dla każdego commita, wybranych gałęzi, pull requestów i tagów, a także potoki uruchamiane ręcznie lub według harmonogramu,
• kroki równoległe, pamięć podręczną zależności (caches) i artefakty przekazywane między krokami,
• usługi pomocnicze, np. bazę danych uruchamianą na czas testów,
• środowiska wdrożeń – domyślnie Test, Staging i Production – z osobnymi zmiennymi, np. innymi kluczami dla testów i produkcji,
• krok uruchamiany ręcznie (trigger: manual), który pokazuje przycisk „Promote” i podgląd zmian przed wdrożeniem,
• gotowe integracje w kontenerach (Pipes), np. wysyłkę plików do Amazon S3.

Panel wdrożeń pokazuje, która wersja działa w którym środowisku, wraz z commitami, zmianami w plikach i zadaniami z Jiry. Wcześniejsze udane wdrożenie można uruchomić ponownie bez przechodzenia całego potoku, o ile jego artefakty nie wygasły – są przechowywane przez 14 dni. W planie Premium można też określić, z których gałęzi wolno wdrażać na dane środowisko.

Zmienne zabezpieczone (secured variables) są szyfrowane i maskowane w logach. Do AWS, Google Cloud czy HashiCorp Vault potok może łączyć się przez OpenID Connect (OIDC) i dostawać tymczasowe poświadczenia zamiast stałych kluczy zapisanych w ustawieniach. Gdy build potrzebuje dostępu do zasobów w sieci firmy, uruchamia się go na własnych maszynach (runners) z Linuksem, Windowsem lub macOS. Atlassian udostępnia też w wersji beta Agentic Pipelines – agentów AI działających w krokach potoku, np. przy analizie kodu.

Ten sam model stosujemy niezależnie od narzędzia. Typowy potok obejmuje instalację zależności, kontrolę jakości kodu, testy, budowanie, wdrożenie na środowisko testowe, akceptację i publikację na produkcji, a po niej sprawdzenie, czy strona odpowiada poprawnie. Sekrety są przechowywane wyłącznie w zabezpieczonych zmiennych systemu CI, nigdy w repozytorium.

Co CI/CD daje firmie

• Powtarzalność – każde wdrożenie przebiega tak samo, niezależnie od tego, kto je uruchamia.
• Kontrola jakości – na produkcję trafia kod, który przeszedł przegląd i testy.
• Historia i powrót do poprzedniej wersji – wiadomo, kto, kiedy i co wdrożył, a wcześniejszą wersję można przywrócić.
• Bezpieczeństwo – dostęp do serwerów i chmury ma system CI z ograniczonymi uprawnieniami, a nie każdy programista z osobna.
• Przejrzystość – kierownik projektu widzi w Jirze, które zadania są już na produkcji.
• Niezależność od wykonawcy – konfiguracja potoku jest częścią repozytorium, więc inny zespół może przejąć projekt bez odtwarzania procesu z pamięci.

Co budujemy i utrzymujemy z Bitbucketem i CI/CD w G2 TEAM

Potoki CI/CD przygotowujemy dla stron internetowych, sklepów, aplikacji webowych i portali – w Bitbuckecie, ale też w innych systemach, z których korzysta klient. Obejmują one m.in.:

• budowanie frontendów i aplikacji, np. w Next.js czy Astro, z testami przy każdym pull requeście,
• wdrożenia na serwery, do AWS z dostępem przez OIDC oraz na Cloudflare Workers za pomocą narzędzia Wrangler,
• środowiska testowe, na których klient akceptuje zmiany przed publikacją,
• automatyczne wdrożenia dla istniejących stron, które dotąd były aktualizowane ręcznie, np. przez FTP.

Repozytorium – w Bitbuckecie, na GitHubie, w GitLabie czy w Azure DevOps – należy do klienta, a kod trafia tam wraz z dokumentacją. Przy stałej opiece nad stroną potok jest częścią utrzymania: aktualizujemy obrazy i zależności, pilnujemy czasu buildów i reagujemy na nieudane wdrożenia. Zakres takiej opieki opisujemy na stronie obsługa stron WWW.

Bitbucket Pipelines a inne narzędzia CI/CD

Narzędzie CI/CD najlepiej dobrać do miejsca, w którym zespół już przechowuje kod i planuje zadania. Same platformy opisujemy na stronach GitHub i Azure DevOps.

Jak wdrażamy CI/CD w projekcie

1. Repozytorium i uprawnienia. Przestrzeń roboczą (workspace) w Bitbuckecie zakładamy na firmę klienta, ustalamy role zespołu, chronimy główną gałąź i włączamy reguły scalania.
2. Budowanie i testy. W pliku bitbucket-pipelines.yml opisujemy instalację zależności, kontrolę jakości, testy i budowanie; niezależne kroki uruchamiamy równolegle, a zależności trafiają do pamięci podręcznej.
3. Środowiska i sekrety. Konfigurujemy środowiska testowe i produkcyjne z osobnymi zmiennymi. Klucze trzymamy w zmiennych zabezpieczonych, a dostęp do AWS – tam, gdzie to możliwe – realizujemy przez OIDC.
4. Wdrożenia. Na środowisko testowe zmiany trafiają automatycznie, a na produkcję po akceptacji, krokiem uruchamianym ręcznie. Przy prostych stronach można przejść na pełne ciągłe wdrażanie.
5. Dokumentacja i przekazanie. W repozytorium opisujemy działanie potoku, wymagane zmienne i sposób przywrócenia poprzedniej wersji, tak aby każdy kolejny zespół mógł go przejąć.

Najczęstsze pytania o Bitbucket i CI/CD

Czy CI/CD ma sens przy małej stronie firmowej?

Tak. Nawet prosty potok – budowanie, test i wdrożenie – zastępuje ręczne wgrywanie plików, które bywa przyczyną rozbieżności między repozytorium a serwerem. Konfiguracja dla małej strony jest zwykle krótka.

Czy musimy przechodzić na Bitbucket?

Nie. Ten sam proces można zbudować w GitHub Actions, GitLab CI/CD czy Azure Pipelines. Bitbucket polecamy przede wszystkim firmom, które planują pracę w Jirze.

Gdzie wykonują się buildy?

Domyślnie w kontenerach Docker w chmurze Atlassiana. Jeśli build musi mieć dostęp do zasobów w sieci firmy albo działać na określonym sprzęcie, korzystamy z własnych runnerów.

Jak bezpiecznie wdrażać do AWS i Cloudflare?

Do AWS potok łączy się przez OpenID Connect i przyjmuje rolę IAM z tymczasowymi poświadczeniami, więc w Bitbuckecie nie są zapisane stałe klucze dostępu. Do Cloudflare używamy tokenu API z uprawnieniami ograniczonymi do wdrażania Workers, zapisanego jako zmienna zabezpieczona.

Uporządkujmy Twoje wdrożenia

Masz projekt, który wciąż jest wgrywany ręcznie, albo potok bez dokumentacji? Mamy za sobą ponad 400 realizacji – stron, sklepów, aplikacji i portali – i wiemy, jak ważny jest przewidywalny proces wdrożeń. Opisz projekt w formularzu „Zapytaj o ofertę” poniżej, a zaproponujemy konfigurację repozytorium i potoku CI/CD.