W dzisiejszym dynamicznym świecie rozwoju oprogramowania proces CI/CD stał się kluczowym elementem usprawniającym pracę zespołów programistycznych. Automatyzacja i usprawnienie etapów rozwoju pozwala na szybsze wykrywanie błędów, lepszą współpracę oraz znaczące skrócenie czasu wprowadzania produktu na rynek.

TeamCity, stworzony przez JetBrains w 2006 roku, jest jednym z wiodących narzędzi CI/CD dostępnym zarówno w wersji komercyjnej, jak i darmowej. Dzięki rozbudowanym możliwościom integracji z popularnymi systemami kontroli wersji oraz frameworkami testowymi, pozwala na łatwe tworzenie i zarządzanie pipeline'ami CI/CD.

W tym artykule przeprowadzimy Cię przez kompleksowy proces wdrażania CI/CD w TeamCity – od podstawowej konfiguracji po zaawansowane techniki automatyzacji.

Podstawy CI/CD i architektura TeamCity

Czym jest proces CI/CD i jakie problemy rozwiązuje

Continuous Integration (CI) to praktyka automatycznego i częstego integrowania zmian w kodzie do wspólnego repozytorium. Umożliwia szybsze wykrywanie błędów poprzez automatyczne budowanie i testowanie kodu po każdej zmianie. Według statystyk, 50% programistów regularnie korzysta z narzędzi CI/CD, a 25% wdrożyło nowe narzędzie w ciągu ostatniego roku.

Continuous Delivery (CD) automatyzuje proces wydawania zwalidowanego kodu do repozytorium, natomiast Continuous Deployment idzie o krok dalej — automatycznie wdraża zmiany na środowisko produkcyjne bez konieczności manualnej interwencji.

Wdrożenie CI/CD pozwala na:

Dostarczanie częstszych wydań, zwiększających wartość dla użytkowników końcowych
Zmniejszanie kosztów rozwoju oprogramowania
Znaczące ograniczanie liczby błędów poprzez wczesne wykrywanie konfliktów w kodzie

Wdrożenie dobrego procesu CI/CD może skrócić czas budowania nawet o 40%, przekładając się bezpośrednio na szybszy czas wprowadzenia produktu na rynek.

Komponenty systemu TeamCity: serwer, agenci i projekty

System TeamCity składa się z dwóch głównych elementów: serwera i agentów budowania.

Serwer TeamCity nie wykonuje samodzielnie buildów ani testów – jego zadaniem jest monitorowanie podłączonych agentów, dystrybuowanie zadań oraz raportowanie wyników. Zapewnia interfejs użytkownika do konfigurowania pipeline'ów, przechowuje szczegóły każdego zadania i inicjuje każde uruchomienie. Wszystkie informacje przechowywane są w bazie danych.

Agent budowania to oddzielna aplikacja, która pobiera kod źródłowy, pobiera artefakty z innych buildów i uruchamia proces budowania. Każdy agent może mieć unikalne środowisko (np. zainstalowane SDK, narzędzia) i w jednym momencie może uruchamiać tylko jedno zadanie.

Porównanie TeamCity z innymi narzędziami CI/CD na rynku

TeamCity jest rozwiązaniem komercyjnym JetBrains, oferującym jednak wersję darmową z ograniczeniami do trzech agentów i nieograniczonym czasem budowania. W porównaniu do Jenkins (open-source), TeamCity wyróżnia się:

Intuicyjnym interfejsem użytkownika niewymagającym rozbudowanej konfiguracji
Self-optimizing build pipelines — automatyczną optymalizacją pipeline'ów
Inteligentną paralelizacją testów
Natywną integracją z Docker, Jira, AWS, Kubernetes, Google Cloud i Microsoft Azure
Lepszymi funkcjami bezpieczeństwa, w tym integracją z pluginem Snyk
Możliwością konfiguracji poprzez GUI oraz Kotlin DSL (konfiguracja jako kod)

Instalacja i konfiguracja środowiska TeamCity

Wymagania systemowe i planowanie instalacji

TeamCity może działać na dowolnym współczesnym systemie Windows, Linux lub macOS. Dla środowiska produkcyjnego zaleca się:

Minimum 4 rdzenie CPU i 16 GB pamięci RAM
Możliwość obsługi do 100 równoczesnych buildów i 200 aktywnych użytkowników
Szybki dostęp do systemu plików (krytyczne dla wydajności serwera)

Dla bazy danych:

Testowo: wbudowana baza HSQLDB (nie zalecana dla produkcji)
Produkcja: MySQL, PostgreSQL lub MS SQL Server
Rozmiar początkowy: minimum 4 GB

Instalacja serwera TeamCity przy użyciu Docker

Najprostsza metoda instalacji to wykorzystanie kontenerów Docker.

Krok 1: Utwórz katalogi dla przechowywania danych:

mkdir datadir logs agent_conf
sudo chown -R 1000:1000 datadir logs agent_conf

Krok 2: Przygotuj plik docker-compose.yml:

version: "2.1"
services:
  server:
    image: jetbrains/teamcity-server:latest
    ports:
      - "8111:8111"
    volumes:
      - datadir:/data/teamcity_server/datadir
      - logs:/opt/teamcity/logs
  agent:
    image: jetbrains/teamcity-agent:latest
    volumes:
      - agent_conf:/data/teamcity_agent/conf
    environment:
      - SERVER_URL=http://server:8111

Krok 3: Uruchom kontenery:

docker-compose up -d

Następnie przejdź pod adres http://localhost:8111, aby dokończyć konfigurację przez przeglądarkę.

Konfiguracja pierwszego agenta budowania

Agent TeamCity to oddzielna aplikacja, która wykonuje faktyczne procesy budowania. Konfiguracja odbywa się poprzez plik buildAgent.properties w katalogu conf:

serverUrl=http://localhost:8111/
name=Default agent
workDir=../work
tempDir=../temp
systemDir=../system

Opis parametrów:

serverUrl — adres serwera TeamCity, do którego agent się podłącza
name — unikalna nazwa agenta widoczna w interfejsie
workDir, tempDir, systemDir — katalogi robocze agenta

Przy instalacji więcej niż jednego agenta na tej samej maszynie należy zmienić port (ownPort) dla każdego z nich, aby uniknąć konfliktu portów.

Zabezpieczanie instalacji TeamCity

Bezpieczeństwo instalacji TeamCity wymaga uwzględnienia kilku aspektów:

Regularne aktualizacje — zawsze utrzymuj TeamCity w najnowszej wersji
Włącz HTTPS — najlepiej poprzez reverse proxy (NGINX lub Apache)
Ogranicz dostęp do katalogu danych tylko do administratorów systemu
Dedykowane konto bazy danych z silnymi poświadczeniami
Niestandardowy klucz szyfrowania do bezpiecznego przechowywania haseł i tokenów
Izolowane agenty — dla buildów z pull requestów od nieznanych użytkowników używaj oddzielnych, izolowanych agentów

Tworzenie efektywnych pipeline'ów w TeamCity

Struktura projektu i konfiguracja VCS

Konfiguracja systemu kontroli wersji (VCS) to pierwszy krok w tworzeniu efektywnego pipeline'u. VCS root definiuje połączenie z repozytorium i zawiera informacje o adresach URL, gałęziach oraz ustawieniach uwierzytelniania.

Jeden VCS root może być podpięty do wielu konfiguracji budowania, co pozwala na ponowne wykorzystanie tych samych ustawień w całym projekcie. Domyślnie TeamCity monitoruje wszystkie gałęzie repozytorium, ale można dostosować, które mają być śledzone poprzez reguły w formacie:

+|-:<branch_name>

Definiowanie kroków budowania (Build Steps)

Kroki budowania są sercem każdej konfiguracji w TeamCity. Można dodać dowolną liczbę kroków, które będą wykonywane sekwencyjnie. Każdy krok dostarcza integrację z konkretnym narzędziem budowania lub testowania.

Dla każdego kroku można określić politykę wykonania:

Tylko gdy status budowania jest pomyślny
Tylko gdy status budowania jest niepomyślny
Jeśli wszystkie poprzednie kroki zakończyły się pomyślnie
Nawet jeśli niektóre z poprzednich kroków nie powiodły się
Zawsze, nawet jeśli wydano polecenie zatrzymania budowania

Implementacja testów automatycznych w pipeline

TeamCity oferuje rozbudowane wsparcie dla testów automatycznych. Testy można skonfigurować jako integralną część pipeline'u CI/CD, a wyniki są dostarczane na bieżąco. Narzędzie automatycznie wyróżnia niestabilne testy oraz nowo nieudane testy, co ułatwia szybką identyfikację problemów.

TeamCity umożliwia również testowanie kodu bez konieczności commitowania go do systemu kontroli wersji — jest to szczególnie przydatne przy pracy w jednej głównej gałęzi, gdzie chcemy zweryfikować zmiany przed ich scaleniem.

Konfiguracja wyzwalaczy (Triggers) dla automatycznych buildów

Wyzwalacze (Triggers) określają, kiedy automatycznie uruchamiać nowy build. TeamCity oferuje kilka typów wyzwalaczy:

VCS Trigger — uruchamia build po wykryciu zmian w repozytorium. Można określić, które gałęzie mają być monitorowane za pomocą filtrów.
Finish Build Trigger — rozpoczyna build obecnej konfiguracji, gdy build wybranej konfiguracji zostanie zakończony. Tworzy to łańcuchy zależności między konfiguracjami.

Odpowiednia konfiguracja wyzwalaczy pozwala na pełną automatyzację procesu CI/CD — od momentu wypchnięcia zmian do repozytorium aż po wdrożenie na produkcję.

Zarządzanie artefaktami i zależnościami

Artefakty to pliki wytworzone podczas budowania (np. skompilowane binaria, raporty testów, pliki konfiguracyjne). TeamCity oferuje dwa rodzaje zależności:

Zależności snapshotowe — tworzą łańcuchy buildów, gdzie konfiguracja „B" nie może uruchomić się, dopóki konfiguracja „A" nie wytworzy odpowiedniego buildu. Zapewniają spójność kodu w całym łańcuchu.

Zależności artefaktowe — pozwalają na przekazywanie plików z jednego buildu do drugiego. Można na przykład użyć artefaktów wytworzonych przez konfigurację „Build" w konfiguracji „Deploy", automatyzując cały cykl dostarczania.

Zaawansowane techniki CI/CD w TeamCity

Wdrażanie aplikacji na środowiska testowe i produkcyjne

TeamCity oferuje specjalny typ konfiguracji budowania — Deployment Configuration (Konfiguracja wdrożeniowa), przeznaczony do dostarczania aplikacji na docelową infrastrukturę.

Unikalne cechy konfiguracji wdrożeniowych:

Przycisk uruchamiający wdrożenie nazywa się „Deploy" zamiast „Run"
Blokują możliwość uruchamiania buildów osobistych
Ograniczają liczbę jednoczesnych buildów do jednego

Zaleca się umieszczanie konfiguracji wdrożeniowych w oddzielnych podprojektach, aby precyzyjnie zarządzać uprawnieniami użytkowników. Dzięki temu można oddzielić deweloperów od osób uprawnionych do wdrażania na produkcję.

Konfiguracja multi-branch pipeline dla projektów Git

W pracy z gałęziami funkcyjnymi (feature branches) TeamCity oferuje zaawansowane mechanizmy konfiguracji. Specyfikacja gałęzi pozwala określić, które gałęzie mają być monitorowane:

+:refs/heads/*

Powyższa reguła śledzi wszystkie istniejące gałęzie funkcyjne. TeamCity automatycznie zapewnia spójność kodu źródłowego dla wszystkich buildów w łańcuchu, nawet jeśli wykorzystują one różne repozytoria i różne typy systemów kontroli wersji.

Parametryzacja buildów i zmienne środowiskowe

Parametry w TeamCity to pary nazwa=wartość, które można wykorzystywać w całej konfiguracji budowania. Trzy główne typy parametrów:

Parametry konfiguracyjne — współdzielenie ustawień w ramach konfiguracji budowania
Zmienne środowiskowe — zaczynające się od prefiksu env., przekazywane do procesu buildu jako zmienne środowiskowe
Właściwości systemowe — zaczynające się od prefiksu system., przekazywane do narzędzi budowania (np. Maven, Gradle)

Przykłady predefiniowanych parametrów TeamCity:

system.teamcity.buildType.id — identyfikator konfiguracji budowania
env.BUILD_NUMBER — numer bieżącego buildu
teamcity.agent.work.dir — katalog roboczy agenta

Parametry można definiować na poziomie projektu (dziedziczone przez podprojekty), konfiguracji budowania lub indywidualnego uruchomienia.

Integracja z narzędziami zewnętrznymi (Jira, Slack, Docker Registry)

TeamCity oferuje natywne integracje z wieloma popularnymi narzędziami:

Integracja z Jira — pozwala na śledzenie szczegółów zgłoszeń wspomnianych w komunikatach commitów i wizualizację postępu każdego zgłoszenia w pipeline CI/CD. Umożliwia dwukierunkowe śledzenie: od commita do zgłoszenia i odwrotnie.

Integracja z Docker Registry — umożliwia automatyczne publikowanie obrazów kontenerów po pomyślnym zakończeniu budowy. Konfiguracja wymaga określenia adresu rejestru i danych logowania. Wspierane są Docker Hub, AWS ECR, Google Container Registry i prywatne rejestry.

Integracja ze Slack — TeamCity może wysyłać powiadomienia do wybranych kanałów Slack, informując zespół o statusie buildów i wdrożeń. Zapewnia to pełną transparentność procesu CI/CD i szybszą reakcję na problemy.

Wnioski

TeamCity stanowi potężne narzędzie CI/CD, które znacząco usprawnia proces wytwarzania oprogramowania. Kluczowe korzyści wdrożenia TeamCity to:

Skrócenie czasu wprowadzania zmian w kodzie na produkcję
Zwiększenie niezawodności procesu wdrożeniowego dzięki automatyzacji
Lepsza kontrola nad jakością kodu poprzez automatyczne testowanie
Sprawniejsza współpraca zespołowa dzięki przejrzystemu interfejsowi i powiadomieniom

Elastyczność TeamCity pozwala na dostosowanie narzędzia do specyficznych potrzeb każdego projektu. Dzięki rozbudowanym możliwościom integracji z popularnymi narzędziami — Jira, Docker, Slack, AWS, Kubernetes — zespoły programistyczne mogą stworzyć spójne i w pełni zautomatyzowane środowisko deweloperskie.

Skuteczne wdrożenie procesu CI/CD wymaga starannego planowania i systematycznego podejścia. Jednak korzyści płynące z automatyzacji procesów znacząco przewyższają początkowy nakład pracy związany z konfiguracją środowiska.

Jeśli potrzebujesz wsparcia we wdrożeniu CI/CD w swoim projekcie, skontaktuj się z nami. W FoxLink Automation pomagamy firmom wdrażać procesy ciągłej integracji i dostarczania — od konfiguracji TeamCity i Jenkins, przez automatyzację testów, aż po pełne pipeline'y wdrożeniowe z Docker i Kubernetes.

Proces CI/CD w TeamCity: Od Podstaw do Praktycznych Wdrożeń