Nie istnieje chyba projekt w którym nie przyda się mechanizm CI/CD. Pozwala on na automatyzację typowych zadań związanych z powstaniem nowej wersji oprogramowania, tj. budowanie, testowanie, dostarczanie, wdrożenie itp.

Do tworzenia swojego bloga wykorzystuję narzędzie Jekyll. Pozawala mi ono na trzymanie treści na gicie. Wiąże się to z tym, że stworzenie nowego artykułu wymaga zbudowania na nowo projektu i wgrania rezultatu na serwer, co w dłuższej perspektywie może być żmudne i nużące. Ciągłe wdrożenie pozwala na automatyzację tego procesu. W związku z tym, że GitLab udostępnia swój mechanizm CI/CD, warto go wykorzystać, jeśli ktoś tak jak ja, korzysta z tego konkretnie hostingu dla gita.

Definicję procesu umieszcza się w pliku .gitlab-ci.yml. Do zbudowania projektu potrzebny będzie Ruby. W tym celu, warto zacząć od zdefiniowania odpowiedniego obrazu dla Dockera z pomocą własności image:

image: ruby:2.3

Warto pamiętać, że Jekyll podczas budowania wykorzystuje zmienne środowiskowe, m.in. po to, aby sprawdzić, czy powinien budować wersję produkcyjną, czy nie. Wszystkie zmienne środowiskowe można zdefiniować w sekcji variables:

variables:
  JEKYLL_ENV: production

Do zbudowania można użyć specjalnej fazy pages, który umożliwia udostępniania wyniku kompilacji z pomocą Gitlab Pages. Oprócz określenia etapu (stage), należy podać kolejne polecenia niezbędne do zbudowania źródeł (script) oraz ścieżki rezultatów:

pages:
  stage: build
  script:
    - bundle install
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - public

Po zbudowaniu projektu, nie pozostaje nic innego jak wgrać wygenerowaną statyczną zawartość w fazie deploy. Aby móc skorzystać z efektów poprzedniego etapu, należy zdefiniować zależności (dependencies). Do kopiowania plików przyda się polecenie scp. Hasło do serwera można przekazać z pomocą komendy sshpass, którą najpierw należy zainstalować. Aby uniknąć przypadkowego wdrożenia zmian tymczasowych, warto okroić używane gałęzie do głównej za pomocą parametru only:

deploy:
  stage: deploy
  dependencies:
    - pages
  script:
    - apt-get update && apt-get install -y sshpass
    - sshpass -p "$PRODUCTION_SFTP_PASSWORD" scp -o stricthostkeychecking=no -P $PRODUCTION_SFTP_PORT -r public/. $PRODUCTION_SFTP_USERNAME@$PRODUCTION_SFTP_HOST:$PRODUCTION_PUBLIC_HTML
  environment:
    name: production
    url: http://blog.wercia.pl
  only:
    - master

Należy pamiętać, że zazwyczaj dane niezbędne do połączenia z serwerem produkcyjnym w celu wdrożenia zmian są zazwyczaj danymi wrażliwymi. W związku z tym należy wystrzegać się podawania ich bezpośrednio w pliku .gitlab-ci.yml. Wsparcie w tej kwesti stanowią zmienne, które można zdefiniować w ustawieniach repozytorium (Setting > CI / CD > Variables).

Po stworzeniu kompletnego pliku .gitlab-ci.yml stanie się zbędne ręczne wdrażanie zmian na serwer. Dzięki temu, każde scalenie zmian z gałęzią główną uruchomi automatyczne budowanie i wgrywanie zmian.

Przykładowy plik .gitlab-ci.yml: