Microsoft Azure — usługi, bezpieczeństwo

Azure DevOps to zestaw narzędzi Microsoft, które działają samodzielnie, ale mogą też współpracować przy tworzeniu oprogramowania: od pomysłu po wdrożenie.¹
Automatyzacja CI/CD, czyli ciągłej integracji i dostarczania zmian, pomaga ograniczać błędy oraz skracać cykl wdrożeniowy.² W artykule omawiamy konfigurację, dostępne usługi i rozwiązywanie problemów w codziennej pracy zespołu DevOps³.

Czym jest Azure DevOps i jak działa w projekcie?

Azure DevOps pomaga organizować pracę nad oprogramowaniem i automatyzować jego dostarczanie. Pipeline CI/CD to sekwencja zadań: buduje aplikację, sprawdza wynik i przygotowuje wdrożenie. Azure Pipelines pozwala skonfigurować automatyczne budowanie oraz wdrażanie aplikacji¹.
W projektach prywatnych bezpłatny agent hostowany przez Microsoft zapewnia 1800 minut działania pipeline’ów miesięcznie⁴.

Azure DevOps udostępnia również wizualny edytor procesów budowania i publikowania⁵. Zespół wskazuje źródło kodu, układa zadania budowania i określa sposób publikacji. Po uruchomieniu procesu może przeanalizować jego wynik.

Szkolenie STACJA.IT dotyczące Azure DevOps obejmuje zbudowanie pipeline’u i uruchomienie budowania aplikacji na platformie Azure⁶. W projekcie taki pipeline prowadzi od zmiany kodu do powtarzalnego budowania i wdrożenia.
Pojedyncze zadanie na bezpłatnym agencie hostowanym przez Microsoft może działać maksymalnie 60 minut⁴.

Jak skonfigurować pipeline CI/CD w Azure DevOps?

Pipeline CI/CD w Azure DevOps konfiguruje się przez wskazanie źródła kodu, zadań budowania i celu wdrożenia. Definicję pojedynczego pipeline’u można zapisać w jednym pliku YAML, zwykle azure-pipelines.yml, umieszczonym obok kodu aplikacji⁷.

• Repozytorium kodu dostarcza pipeline’owi pliki aplikacji. Wybierz repozytorium oraz gałąź, od której ma zaczynać się proces.
• Wyzwalacz określa moment uruchomienia pipeline’u. Możesz powiązać go ze zmianą w wybranej gałęzi albo uruchamiać proces ręcznie podczas konfiguracji.
• Zadania budowania instalują zależności, kompilują aplikację i wykonują testy właściwe dla projektu. Ułóż je w kolejności, której wymaga aplikacja.
• Etap wdrożenia publikuje wynik budowania w wybranym środowisku. Zanim go uruchomisz, wskaż potrzebne połączenie i uprawnienia.

Historia uruchomień pokazuje wyniki budowania i wdrażania w skonfigurowanym pipeline’ie⁸.
Planując pracę na bezpłatnym agencie hostowanym przez Microsoft, uwzględnij limit 60 minut na pojedyncze zadanie⁴.

Jak znaleźć przyczynę błędu pipeline’u i go naprawić?

Gdy pipeline kończy się błędem, zacznij od nieudanego uruchomienia i komunikatu przypisanego do zadania. Wyniki oraz logi pozwalają szukać przyczyny na poziomie etapu, zadania i kroku⁹.

• Nieudane uruchomienie pokazuje, na którym etapie proces się zatrzymał. Otwórz historię i znajdź pierwsze zadanie zakończone błędem.
• Dziennik zadania zawiera komunikat potrzebny do rozpoznania problemu. Przeczytaj go przed zmianą konfiguracji, żeby nie poprawiać niewłaściwego etapu¹⁰.
• Źródło błędu może tkwić w kodzie, zależnościach, konfiguracji zadania lub uprawnieniach do środowiska. Porównaj komunikat z ustawieniami nieudanego etapu i popraw wskazany element¹⁰.
• Ponowne uruchomienie pozwala sprawdzić poprawkę. Uruchom pipeline dla zmienionego kodu lub konfiguracji, a potem porównaj wynik z poprzednią próbą⁸.

Naprawę można uznać za zakończoną, gdy poprawiony etap przechodzi, a cały proces osiąga zamierzony wynik¹⁰.

Czym są usługi i wersje Azure DevOps?

Azure DevOps obejmuje 5 narzędzi do zarządzania pracą, kodem, budowaniem, testami i artefaktami. Jest dostępny jako chmurowa usługa Services oraz wersja Server instalowana na własnej infrastrukturze¹. Narzędzia obsługują różne etapy projektu, dzięki czemu zespół może powiązać zadanie ze zmianą kodu i wynikiem budowania.
W Azure DevOps Services plan Basic jest bezpłatny dla pierwszych pięciu użytkowników¹¹.

Marketplace Azure DevOps oferuje narzędzia bezpłatne oraz komercyjne rozszerzenia⁵. Rozszerzenie może uzupełnić używany proces, ale nie zastępuje decyzji o wyborze Services albo Server.

Do czego służą Boards, Repos, Pipelines, Test Plans i Artifacts?

Boards, Repos, Pipelines, Test Plans i Artifacts obsługują kolejno zadania, kod, automatyzację dostarczania, testy oraz pakiety. W każdej organizacji Azure Artifacts udostępnia bezpłatnie 2 GiB miejsca na pakiety¹².

• Azure Boards porządkuje zadania i ich statusy, aby zespół mógł śledzić zakres pracy¹³.
• Azure Repos przechowuje repozytoria kodu wraz z historią zmian.
• Azure Pipelines uruchamia procesy budowania i wdrażania aplikacji.
• Azure Test Plans pomaga organizować testy oraz analizować wyniki.
• Azure Artifacts pozwala udostępniać pakiety wykorzystywane w projekcie.

Azure DevOps dostarcza szczegółowe raporty z testowania i obsługuje wyniki w formacie JUnit⁵. Obsługiwane typy testów obejmują też NUnit, xUnit i VSTests⁵.
Jeśli plików z wynikami jest ponad 100, zadanie Publish Test Results scala je w jedno uruchomienie testów, nawet przy wyłączonym scalaniu¹⁴.

Koszty GitLab i Azure DevOps: co porównać?

Koszty GitLab i Azure DevOps warto porównywać pod kątem liczby użytkowników, automatyzacji zadań i utrzymania infrastruktury. Porównanie Deviniti wskazuje 2 plany finansowania Azure DevOps⁵.

Poniższa tabela zbiera podane stawki i limity, które mogą wpłynąć na koszt wyboru.

Dane w tabeli: 1,11,15,16

Przy zestawianiu GitLab self-managed z usługą chmurową same stawki za użytkowników nie wystarczą. W rachunku trzeba też uwzględnić koszty infrastruktury i administracji po obu stronach.

Czym różnią się Azure DevOps Services i Azure DevOps Server?

Azure DevOps Services działa w chmurze, natomiast Azure DevOps Server organizacja instaluje i utrzymuje na własnej infrastrukturze. Szkolenie Sages dotyczące Azure DevOps omawia różnice między tymi wersjami¹⁷.

Tabela pokazuje, kto odpowiada za utrzymanie platformy i jak często każda wersja otrzymuje nowe funkcje.

Dane w tabeli: 18,19

Azure DevOps w procesie tworzenia oprogramowania

Azure DevOps pozwala powiązać pracę nad kodem z kontrolą zmian i dostarczaniem aplikacji. Zadanie określa oczekiwaną zmianę, a przegląd kodu daje zespołowi okazję do omówienia jej przed wdrożeniem.
Przykładowa polityka gałęzi main może wymagać zatwierdzenia pull requestu przez co najmniej dwóch recenzentów²⁰.

Azure DevOps pozwala utworzyć repozytorium Git lub TFS i prowadzić pull requesty z komentarzami do zdalnego przeglądu kodu¹. Pull request to propozycja włączenia zmian do wybranej gałęzi. Azure Repos obsługuje dwa typy kontroli wersji: Git i TFVC; „TFS” nie jest nazwą drugiego typu²¹.

Automatyzacja wdrożeń wiąże zatwierdzoną zmianę z dostarczeniem aplikacji do środowiska. Zespół może oddzielić przegląd kodu od decyzji o publikacji, stosując na przykład wymóg zatwierdzenia pull requestu przez co najmniej dwóch recenzentów²⁰.

Przykłady zastosowań usług Azure DevOps w firmach

Azure DevOps może wspierać przegląd zmian, obsługę poprawek i dostarczanie kolejnych wersji aplikacji. Dobór usług zależy od tego, czy zespół najbardziej potrzebuje kontroli kodu, koordynacji pracy czy automatyzacji wdrożeń³.
W prywatnym projekcie korzystającym z automatyzacji trzeba uwzględnić 1800 minut miesięcznie na bezpłatnym agencie hostowanym przez Microsoft⁴.

• Przegląd zmian w aplikacji daje zespołowi możliwość omówienia kodu przed włączeniem go do używanej gałęzi.
• Obsługa poprawki wiąże opis błędu z pracą programistów nad zmianą i jej weryfikacją²².
• Dostarczanie nowej wersji porządkuje drogę od zatwierdzonej zmiany do wdrożenia aplikacji.

DevOps w praktyce: korzyści, ograniczenia i przebieg pracy

DevOps łączy tworzenie oprogramowania z jego dostarczaniem, a Azure DevOps pomaga prowadzić te prace w powiązanych narzędziach. Zebranie narzędzi w jednym miejscu ułatwia zespołowi współpracę i zarządzanie zmianami².
Zespół musi też ustalić, kto zatwierdza kod, uruchamia wdrożenie i reaguje na nieudane testy. Przykładowa polityka gałęzi main przewiduje co najmniej dwóch recenzentów²⁰.

Jakie korzyści może dać Azure DevOps?

Azure DevOps pomaga połączyć zadania, zmiany kodu i wyniki automatyzacji w procesie obejmującym 5 narzędzi¹. Powiązanie zmiany z zadaniem wyjaśnia jej cel. Wynik uruchomienia pipeline’u pokazuje z kolei, czy dostarczenie aplikacji się powiodło.
Taki proces działa lepiej, gdy zespół konsekwentnie opisuje zmiany i analizuje nieudane uruchomienia.

Jak zbudować proces pracy w Azure DevOps?

Azure DevOps pozwala ułożyć pracę od zadania i zmiany kodu, przez testy, aż po wdrożenie. Przykładowa polityka gałęzi main może wymagać zatwierdzenia zmiany przez co najmniej dwóch recenzentów²⁰.

• Organizacja i projekt wyznaczają przestrzeń pracy zespołu. Przypisz do niej osoby odpowiedzialne za kod, testy i wdrożenia.
• Zmiana kodu powinna mieć opis celu i przejść przegląd przed włączeniem do gałęzi projektu. Komentarze w pull requeście umożliwiają zdalne omówienie zmian.
• Pipeline powinien uruchamiać budowanie i testowanie przyjętych zmian. Jeśli wynik jest nieudany, przed wdrożeniem popraw kod lub konfigurację²³.
• Wdrożenie powinno korzystać z uprawnień i sekretów właściwego środowiska. Wyznacz osobę, która odpowiada za zatwierdzenie publikacji.

Program szkolenia Sages z Azure DevOps obejmuje organizacje i projekty, repozytoria, pipeline’y, sekrety, wdrożenia oraz testowanie¹⁷. Szkolenie „Wytwarzanie i dostarczanie oprogramowania w kulturze DevOps z użyciem Azure DevOps” trwa 2 dni (16 h); podany termin to 30–31 grudnia¹⁷. Cena wynosi 2150 PLN netto, czyli 2644,50 PLN brutto za uczestnika po doliczeniu 23% VAT¹⁷. Dofinansowanie może wynieść maksymalnie 100%, lecz nie jest dostępne dla instytucji publicznych¹⁷.

Proces jest gotowy do użycia, gdy wiadomo, kto odpowiada za przegląd kodu, testy i wdrożenie.

Jakie ograniczenia Azure DevOps uwzględnić?

Azure DevOps wymaga osobnych rozwiązań do funkcji, których nie zapewnia wbudowany zestaw 5 narzędzi¹. Porównanie Deviniti wskazuje brak wbudowanego systemu zarządzania sekretami i analizatora bezpieczeństwa⁵.
Projektując proces, zespół powinien więc uwzględnić obsługę sekretów i analizę bezpieczeństwa. Sam pipeline nie zapewnia pełnej kontroli bezpieczeństwa.

Czym jest DevOps i jak łączy pracę zespołów?

DevOps zakłada wspólną odpowiedzialność osób tworzących oprogramowanie i utrzymujących środowiska za dostarczenie zmian. Programiści przekazują kod do przeglądu, a osoby odpowiedzialne za wdrożenia ustalają warunki publikacji. Wyniki testów i wdrożeń wracają do zespołu, który może wykorzystać je przy następnej zmianie²⁴.

DevOps łączy zespoły, gdy odpowiedzialność za zmianę obejmuje również jej testowanie i działanie po wdrożeniu.
Przykładowa polityka gałęzi main może przy tym wymagać zatwierdzenia kodu przez co najmniej dwóch recenzentów²⁰.

Jak dobrać narzędzie DevOps do zadania?

Narzędzie DevOps dobierz do zadania, oceniając kandydatów według tych samych wymagań dotyczących kodu, automatyzacji, bezpieczeństwa i utrzymania. Jeśli rozważasz Azure DevOps Services, uwzględnij bezpłatny plan Basic dla pierwszych pięciu użytkowników. Każdy kolejny kosztuje 6 USD miesięcznie¹⁵.

• Określenie zadania zespołu wyznacza zakres potrzebnego narzędzia. Zapisz, czy ma obsługiwać przegląd kodu, testy, wdrożenia czy cały proces dostarczania aplikacji.
• Ustalenie miejsca przechowywania kodu pozwala wziąć pod uwagę istniejące repozytorium. Porównaj, jak każde narzędzie uruchamia proces po zmianie kodu.
• Opis wymagań wdrożeniowych wskazuje środowisko docelowe, sposób zatwierdzania publikacji i uprawnienia potrzebne procesowi.
• Porównanie bezpieczeństwa i utrzymania obejmuje sekrety, kontrolę dostępu oraz odpowiedzialność za infrastrukturę. GitHub Actions uwzględnij, jeśli zespół rozważa automatyzację powiązaną z pracą w GitHubie.

Wybór narzędzia DevOps powinien wynikać z wymagań procesu i skali zespołu, nie z samej listy dostępnych funkcji.

Jak włączyć zespół bezpieczeństwa w istniejący proces DevOps?

Azure DevOps pozwala włączyć zespół bezpieczeństwa w proces wdrażania przez przypisanie odpowiedzialności za dostęp, sekrety i zatwierdzanie publikacji. Przy planowaniu dostępu do Azure DevOps Services uwzględnij bezpłatny plan Basic dla pierwszych pięciu użytkowników¹¹.

• Zespół bezpieczeństwa powinien wskazać środowiska, które wymagają zatwierdzenia przed publikacją. Ustal, kto decyduje o wdrożeniu do każdego z nich.
• Zatwierdzanie publikacji w Azure DevOps można przypisać wskazanym użytkownikom lub grupom⁵. Powierz tę rolę osobom odpowiedzialnym za ocenę bezpieczeństwa wdrożenia.
• Dostęp do środowisk wymaga przeglądu uprawnień osób i grup uczestniczących w procesie. Odróżnij Azure Active Directory, usługę zarządzania tożsamościami znaną dziś jako Microsoft Entra ID, od Active Directory działającego w infrastrukturze organizacji.
• Sekrety wdrożeniowe, takie jak hasła i klucze dostępu, powinny trafiać wyłącznie do procesów i osób, które ich potrzebują. Ustal z zespołem bezpieczeństwa zasady przechowywania i wymiany sekretów bez umieszczania ich wartości w kodzie.

Zespół bezpieczeństwa ma określoną rolę w procesie DevOps, gdy podejmuje decyzje o publikacji i ustala zasady dostępu do środowisk oraz sekretów.

Ceny i warunki sprawdzone u źródeł: październik 2026.