Artykuły
Samouczki
Interaktywne przewodniki
Naucz się ciągłego wdrażania z Bitbucket Pipelines
Sten Pittet
Autor współpracujący
W tym przewodniku zobaczysz, jak można zaimplementować proces ciągłego wdrażania za pomocą Bitbucket Pipelines
Czas
30 minut
Publiczność
Osoby, które dopiero zaczynają stosować ciągłe wdrażanie, i/ lub początkujący użytkownicy Bitbucket Pipelines
Tworzenie oprogramowania często wymaga poważnych kompromisów. Zwykle uważa się, że przyspieszenie prac nieodzownie wiąże się z obniżeniem jakości wydań aplikacji. Istnieje jednak praktyka związana z tworzeniem oprogramowania, która pozwoli zaoszczędzić czas dzięki szybszemu wydawaniu. Jest nią ciągłe wdrażanie.
Ciągłe wdrażanie eliminuje stres związany z tą operacją dzięki automatyzacji. Zespół programistów nie musi już przerywać pracy i przełączać kontekstu, aby przygotować wydanie — kod jest dostarczany klientom, gdy tylko programista ukończy pracę.
W tym przewodniku zobaczysz, jak można zaimplementować proces ciągłego wdrażania za pomocą Bitbucket Pipelines.
Ciągłe dostarczanie a ciągłe wdrażanie
Praktyka ciągłego dostarczania polega na zapewnianiu ciągłej gotowości kodu do wydania, nawet jeśli nie każda zmiana jest wdrażana w środowisku produkcyjnym. Zaleca się możliwie jak najczęstsze aktualizowanie środowiska produkcyjnego, aby zakres zmian był niewielki, jednak ostatecznie to Ty kontrolujesz rytm swoich wydań.
W przypadku ciągłego wdrażania nowe zmiany wypychane do repozytorium są automatycznie wdrażane w środowisku produkcyjnym, jeśli pomyślnie przejdą testy. Większy nacisk (a więc i większą presję) kładzie się wówczas na kulturę testowania. Jest to jednak doskonały sposób na przyspieszenie wymiany informacji zwrotnych z klientami.
Konfiguracja pipeline'u ciągłego wdrażania
W tym przykładzie rozbudujemy prostą aplikację w środowisku Node.js, którą skompilowaliśmy w przewodniku <łącze do artykułu 2>, dodając pipeline ciągłego wdrażania. Ciągłe wdrażanie to dla zespołów doskonały sposób na przyspieszenie tworzenia oprogramowania. Eliminuje przeszkody związane z procesem zatwierdzania wydań i umożliwia programistom gromadzenie opinii od klientów bezpośrednio po zakończeniu prac. Wyszukiwanie i usuwanie problemów staje się łatwiejsze, a dzięki wyeliminowaniu czasu przeznaczonego na wydawanie można ograniczyć zmiany kontekstów.
Konfiguracja pipeline'u ciągłego wdrażania w Bitbucket Pipelines jest bardzo prosta. Zobaczymy, jak można ją przeprowadzić przy użyciu prostej aplikacji Hello World, która przejdzie przez środowisko przejściowe oraz testy akceptacyjne, zanim nastąpi automatyczne wydanie kodu do środowiska produkcyjnego.
Krok 1: Utworzenie nowej aplikacji Heroku
W samouczku dotyczącym ciągłego dostarczania wypchnęliśmy gałąź ze scaleniami do aplikacji Heroku w wersji produkcyjnej. Teraz utworzymy kolejną aplikację Heroku, aby uniknąć konfliktów podczas wypychania kodu w ramach tego samouczka. Wykonaj następujące polecenie:
heroku create --remote production2
git push production2 mainTeraz polecenie git remote -vv zwraca wartość zbliżoną do poniższej. W dalszej części tego samouczka używaj środowisk staging oraz production2.
wmarusiak@C02F207NML7L cdtutorial % git remote -vv
origin git@bitbucket.org:pmmquickstartguides01/cdtutorial.git (fetch)
origin git@bitbucket.org:pmmquickstartguides01/cdtutorial.git (push)
production https://git.heroku.com/fierce-basin-45507.git (fetch)
production https://git.heroku.com/fierce-basin-45507.git (push)
production2 https://git.heroku.com/limitless-headland-92324.git (fetch)
production2 https://git.heroku.com/limitless-headland-92324.git (push)
staging https://git.heroku.com/thawing-river-12585.git (fetch)
staging https://git.heroku.com/thawing-river-12585.git (push)Krok 2: Konfiguracja pipeline'u
Nasz przepływ pracy będzie prosty:
- Kompilacja aplikacji.
- Przeprowadzenie testów kompilacji.
- Wdrożenie do środowiska przejściowego.
- Przeprowadzenie testów akceptacyjnych w środowisku przejściowym.
- Wdrożenie w środowisku produkcyjnym.
Zobaczysz, że utworzenie odpowiedniej konfiguracji pipeline'u jest bardzo łatwe. Zaczniemy od dodania naszego automatycznego wdrożenia do środowiska przejściowego, aby się upewnić, że każde wypchnięcie przebiega prawidłowo.
image: node:16
clone:
depth: full
pipelines:
branches:
main:
- step:
name: deploy_to_staging
script:
- npm install
- npm test
- git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git mainPamiętaj o zastąpieniu adresu URL wypchnięć w systemie Git dla gałęzi main adresem URL środowiska przejściowego z polecenia git remote -vv.
Zauważysz, że używamy pełnego klonowania, aby mieć pewność, że aplikacja Heroku nie odrzuci naszego wypchnięcia. Następnie użyjemy również pipeline'u właściwego dla gałęzi, aby środowisko przejściowe było wdrażane wyłącznie w odniesieniu do zmian wypchniętych do gałęzi main, a nie innych gałęzi. Konfigurację tę można wypchnąć do Bitbucket, aby sprawdzić, jak działa.
Automatyczne wdrażanie do środowiska przejściowego zostało ukończone
Na tym etapie mamy teraz naszą aplikację Hello World wdrożoną w środowisku przejściowym.
Możemy teraz przejść do kolejnego kroku i dodać nasze testy akceptacyjne. Testy akceptacyjne mają na celu sprawdzenie, czy nasza aplikacja będzie zachowywać się w oczekiwany sposób w środowisku przejściowym (staging), czyli imitującym środowisko produkcyjne. Chcemy wyeliminować niepewności wynikające z różnic konfiguracyjnych między środowiskiem używanym do testowania kompilacji a środowiskiem produkcyjnym.
Jeśli przyjrzysz się kodowi naszej aplikacji, zauważysz, że nasz test wykonuje bardzo prostą czynność — sprawdza, czy na stronie występuje fraza „Hello World”. W przypadku prawdziwych aplikacji zalecamy przeprowadzanie znacznie szerzej zakrojonych testów akceptacyjnych i sprawdzenie, czy wszystkie usługi podstawowe wykorzystywane przez aplikację (baza danych, pamięć podręczna, usługi innych firm itp.) działają prawidłowo.
Aby dodać test akceptacyjny, wykonaj następujące kroki:
mkdir acceptance-test
touch acceptance-test/test.jsNastępnie edytuj plik acceptance-test/test.js i dodaj następujący fragment kodu.
var request = require('supertest');
// Running a test on our staging environment
describe('GET /', function() {
it('displays "Hello World!" on staging', function(done) {
var staging_url = 'https://' + process.env.HEROKU_STAGING + '.herokuapp.com'
// The line below is the core test of our app.
request(staging_url).get("/").expect("Hello World!", done);
});
});Zaktualizuj plik package.json, dodając polecenie --timeout 10000.
{
"name": "cdtutorial",
"version": "1.0.0",
"description": "",
"main": "server.js",
"scripts": {
"start": "node server.js",
"test": "mocha --exit --timeout 10000"
},
"repository": {
"type": "git",
"url": "git+ssh://git@bitbucket.org/pmmquickstartguides01/cdtutorial.git"
},
"author": "",
"license": "ISC",
"bugs": {
"url": "https://bitbucket.org/pmmquickstartguides01/cdtutorial/issues"
},
"homepage": "https://bitbucket.org/pmmquickstartguides01/cdtutorial#readme",
"dependencies": {
"express": "^4.17.3"
},
"devDependencies": {
"mocha": "^9.2.2",
"supertest": "^6.2.2"
}
}Dodajmy zatem nasz test tuż za naszym wdrożeniem w środowisku przejściowym.
image: node:16
clone:
depth: full
pipelines:
branches:
main:
- step:
script:
- npm install
- npm test
- git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
- HEROKU_STAGING=thawing-river-12585 npm test acceptance-testPamiętaj o zastąpieniu adresu URL wypchnięć w systemie Git dla gałęzi main adresem URL środowiska przejściowego z polecenia git remote -vv.
Po wypchnięciu tej nowej konfiguracji do Bitbucket nasz pipeline zostanie pomyślnie ukończony.
Bitbucket Pipelines będzie teraz przeprowadzać testy akceptacyjne po wdrożeniu do środowiska przejściowego
Teraz pozostaje tylko dodać nasze wdrożenie produkcyjne na końcu, aby ukończyć pipeline ciągłego wdrażania.
image: node:16
clone:
depth: full
pipelines:
branches:
main:
- step:
script:
- npm install
- npm test
- git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
- HEROKU_STAGING=thawing-river-12585 npm test acceptance-test
- git push https://heroku:$HEROKU_API_KEY@git.heroku.com/limitless-headland-92324.git mainZastąp adres URL przy poleceniu git push dla gałęzi main adresem URL środowiska przejściowego z wiersza git remote -vv, a adres URL przy poleceniu git push dla środowiska produkcyjnego adresem URL production2 z polecenia git remote -vv.
Ostateczne wypchnięcie do Bitbucket spowoduje przeprowadzenie naszych zmian w kodzie przez cały pipeline, utworzenie i przetestowanie kodu, a następnie wdrożenie go w środowisku produkcyjnym po uprzednim sprawdzeniu poprawności jego działania w środowisku przejściowym. W tym przypadku strona główna została zaktualizowana o inny komunikat potwierdzający wdrożenie aplikacji w środowisku produkcyjnym.
Nasz nowy komunikat trafił do środowiska produkcyjnego zgodnie z oczekiwaniami!
Sprawdzanie, czy kod został przepuszczony przez pipeline
Istotne jest podkreślenie wagi posiadania dobrego pakietu testów oraz procedur monitorowania w czasie rzeczywistym, zanim wprowadzi się zasadę ciągłego wdrażania we własnych repozytoriach. Od tej pory zmiany będą trafiały do środowiska produkcyjnego, gdy tylko zostaną wypchnięte do gałęzi main, dlatego tym ważniejsze staje się zapewnienie, aby zautomatyzowane testy faktycznie sprawdzały krytyczne części aplikacji. Dodatkowo potrzebne są narzędzia monitorowania do wykrywania zmian wpływających niekorzystnie na instancje produkcyjne, które mogą powodować całkowitą awarię lub pogorszenie jakości usługi.
Ostateczną wersję źródła znajdziesz w repozytorium Bitbucket Cloud pod poniższym łączem.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Społeczność DevOps
Ścieżka szkoleniowa DevOps
