Close

Naucz się ciągłego wdrażania z Bitbucket Pipelines

Portret Stena Pitteta
Sten Pittet

Autor współpracujący

W tym przewodniku zobaczysz, jak można zaimplementować proces ciągłego wdrażania za pomocą Bitbucket Pipelines

Godzina

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 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 trafia do klientów, 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.

Schemat przedstawiający różnicę między ciągłym wdrażaniem a ciągłym tworzeniem | CI/CD w Atlassian

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 main

Teraz 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 main

Pamię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.

Wypychanie konfiguracji do Bitbucket Pipelines

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.

Zrzut ekranu aplikacji „Hello World” wdrożonej w środowisku stagingowym

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.js

Nastę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-test

Pamiętaj o zastąpieniu adresu URL wypchnięć w systemie Git dla gałęzi main adresem URL środowiska stagingowego z polecenia git remote -vv.

Po wypchnięciu tej nowej konfiguracji do Bitbucket nasz pipeline zostanie pomyślnie ukończony.

Sprawna realizacja pipeline'u w Bitbucket

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 main

Zastą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.

Zaktualizowano komunikat na stronie głównej, aby potwierdzić wdrożenie w środowisku produkcyjnym: „Hello World! Straight to production!” (Witaj świecie! Prosto do produkcji!).

Nasz nowy komunikat trafił do środowiska produkcyjnego zgodnie z oczekiwaniami!

Zakończono pipeline ciągłego wdrażania w Bitbucket

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.

Sten Pittet
Sten Pittet

I've been in the software business for 10 years now in various roles from development to product management. After spending the last 5 years in Atlassian working on Developer Tools I now write about building software. Outside of work I'm sharpening my fathering skills with a wonderful toddler.


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.

Ilustracja DevOps

Społeczność DevOps

Ilustracja DevOps

Warsztaty symulacyjne

Ilustracja przedstawiająca mapę

Zacznij korzystać za darmo

Zapisz się do newslettera DevOps

Thank you for signing up