Migrowanie z usługi Jenkins do usługi Azure Pipelines

Azure DevOps Services

Jenkins, serwer automatyzacji typu open source, jest tradycyjnie instalowany przez przedsiębiorstwa we własnych centrach danych i zarządzanych lokalnie. Wielu dostawców oferuje również hosting zarządzany przez usługę Jenkins.

Alternatywnie, usługa Azure Pipelines to natywne w chmurze rozwiązanie do ciągłej integracji. Zapewnia ona zarządzanie potokami wielostopniowymi i agentem kompilacji Azure Virtual Machines hostowanymi w chmurze.

Usługa Azure Pipelines oferuje również w pełni lokalną opcję z usługą Azure DevOps Server dla klientów, którzy mają problemy ze zgodnością lub zabezpieczeniami, które wymagają od nich zachowania kodu i tworzenia w centrum danych przedsiębiorstwa.

Ponadto usługa Azure Pipelines obsługuje modele chmury hybrydowej i modeli lokalnych. Usługa Azure Pipelines może zarządzać orkiestracją kompilacji i wydaniami oraz umożliwia korzystanie z agentów zarówno w chmurze, jak i zainstalowanych na miejscu.

Ten artykuł zawiera przewodnik dotyczący tłumaczenia konfiguracji potoku serwera Jenkins na usługę Azure Pipelines. Zawiera on informacje na temat przenoszenia kompilacji opartych na kontenerach i wybierania agentów kompilacji, mapowania zmiennych środowiskowych oraz sposobu obsługi powodzenia i niepowodzeń potoku kompilacji.

Konfiguracja

Zapoznasz się ze znanym przejściem z potoku deklaratywnego usługi Jenkins do konfiguracji YAML usługi Azure Pipelines. Te dwa są koncepcyjnie podobne, obsługując "konfigurację jako kod" i umożliwiając sprawdzenie konfiguracji w systemie kontroli wersji. W przeciwieństwie do Jenkins usługa Azure Pipelines używa jednak standardu YAML stosowanego w branży do konfigurowania potoku kompilacji.

Pojęcia między usługami Jenkins i Azure Pipelines i sposób ich konfigurowania są podobne. Plik Jenkinsfile zawiera co najmniej jeden etap procesu kompilacji, z których każdy zawiera co najmniej jeden krok , który jest wykonywany w kolejności. Na przykład etap "build" może uruchomić zadanie w celu zainstalowania zależności wymaganych podczas budowania, a następnie wykonać krok kompilacji. Podczas gdy etap "testowy" może wywołać uprzężę testową względem plików binarnych utworzonych na etapie kompilacji.

Przykład:

Jenkinsfile

pipeline {
    agent none
    stages {
        stage('Build') {
            steps {
                sh 'npm install'
                sh 'npm run build'
            }
        }
        stage('Test') {
            steps {
                sh 'npm test'
            }
        }
    }
}

Plik jenkinsfile łatwo tłumaczy się na konfigurację YAML usługi Azure Pipelines z zadaniem odpowiadającym każdemu etapowi i krokami do wykonania w każdym zadaniu:

azure-pipelines.yml

jobs:
- job: Build
  steps:
  - script: npm install
  - script: npm run build
- job: Test
  steps:
  - script: npm test

Kompilacje oparte na kontenerach

Używanie kontenerów w potoku budowania pozwala na budowanie i testowanie w obrazie Dockera zawierającym dokładne zależności, które są potrzebne potokowi i które są już skonfigurowane. Pozwala to zaoszczędzić na konieczności uwzględnienia kroku kompilacji, który instaluje więcej oprogramowania lub konfiguruje środowisko. Zarówno usługi Jenkins, jak i Azure Pipelines obsługują kompilacje oparte na kontenerach.

Ponadto zarówno Jenkins, jak i Azure Pipelines umożliwiają udostępnianie katalogu kompilacji z agenta hosta do woluminu kontenera przy użyciu flagi -v dla Docker. Dzięki temu można połączyć wiele zadań kompilacji, które mogą używać tych samych źródeł i zapisywać w tym samym katalogu wyjściowym. Jest to szczególnie przydatne w przypadku korzystania z wielu różnych technologii w stosie; możesz utworzyć backend przy użyciu kontenera .NET Core i frontend z kontenerem TypeScript.

Aby na przykład uruchomić kompilację w kontenerze ubuntu 22.04 ("Jammy"), a następnie uruchomić testy w kontenerze Ubuntu 24.04 ("Noble"):

Jenkinsfile

pipeline {
    agent none
    stages {
        stage('Build') {
            agent {
                docker {
                    image 'ubuntu:jammy'
                    args '-v $HOME:/build -w /build'
                }
            }
            steps {
                sh 'make'
            }
        }
        stage('Test') {
            agent {
                docker {
                    image 'ubuntu:noble'
                    args '-v $HOME:/build -w /build'
                }
            }
            steps {
                sh 'make test'
            }
        }
    }
}

Usługa Azure Pipelines udostępnia zadania kontenera umożliwiające uruchamianie kompilacji w kontenerze:

azure-pipelines.yml

resources:
  containers:
  - container: jammy
    image: ubuntu:jammy
  - container: noble
    image: ubuntu:noble

jobs:
- job: build
  container: jammy
  steps:
  - script: make
- job: test
  dependsOn: build
  container: noble
  steps:
  - script: make test

Ponadto usługa Azure Pipelines udostępnia zadanie platformy Docker , które umożliwia uruchamianie, kompilowanie lub wypychanie obrazu.

Wybór agenta

Jenkins oferuje wybór agenta kompilacji przy użyciu opcji agent, aby upewnić się, że potok kompilacji — lub określony etap potoku — działa na określonej maszynie agenta kompilacji. Podobnie usługa Azure Pipelines oferuje wiele opcji konfigurowania miejsca uruchamiania środowiska kompilacji.

Wybór hostowanego agenta

Usługa Azure Pipelines oferuje agentów kompilacji hostowanych w chmurze dla kompilacji systemów Linux, Windows i macOS. Aby wybrać środowisko kompilacji, możesz użyć odpowiedniego polecenia. vmimage słowo kluczowe. Aby na przykład wybrać kompilację systemu macOS:

pool:
  vmimage: macOS-latest

Ponadto można określić container i określić obraz platformy Docker w celu uzyskania bardziej szczegółowej kontroli nad sposobem uruchamiania kompilacji.

Wybór agenta lokalnego

Jeśli hostujesz agentów kompilacji lokalnie, możesz zdefiniować agenta kompilacji "możliwości" na podstawie architektury maszyny lub zainstalowanego na nim oprogramowania. Jeśli na przykład skonfigurowaliśmy lokalnego agenta kompilacji z java funkcjami, możesz upewnić się, że zadanie działa na nim przy użyciu słowa kluczowego demands :

pool:
  demands: java

Zmienne środowiskowe

W usłudze Jenkins zwykle definiuje się zmienne środowiskowe dla całego pipeline'u. Aby na przykład ustawić dwie zmienne środowiskowe, CONFIGURATION=debug i PLATFORM=x86:

Jenkinsfile

pipeline {
    agent any
    environment {
        CONFIGURATION = 'debug'
        PLATFORM      = 'x64'
    }
    stages {
        stage('Build') {
            steps {
                sh 'echo $CONFIGURATION $PLATFORM'
            }
        }
    }
}

Podobnie w usłudze Azure Pipelines można skonfigurować zmienne, które są używane zarówno w ramach konfiguracji YAML, jak i są ustawiane jako zmienne środowiskowe podczas wykonywania zadania:

azure-pipelines.yml

variables:
  configuration: debug
  platform: x64

Ponadto w usłudze Azure Pipelines można zdefiniować zmienne, które są ustawiane tylko podczas określonego zadania:

azure-pipelines.yml

jobs:
- job: debug build
  variables:
    configuration: debug
  steps:
  - script: ./build.sh $(configuration)
- job: release build
  variables:
    configuration: release
  steps:
  - script: ./build.sh $(configuration)

Wstępnie zdefiniowane zmienne

Zarówno narzędzia Jenkins, jak i Azure Pipelines ustawiają szereg zmiennych środowiskowych , które ułatwiają inspekcję i interakcję ze środowiskiem wykonywania systemu ciągłej integracji.

Description	Jenkins	Azure Pipelines
Unikatowy identyfikator liczbowy dla wywołania bieżącej kompilacji.	`BUILD_NUMBER`	`BUILD_BUILDNUMBER`
Unikatowy identyfikator (niekoniecznie liczbowy) dla wywołania bieżącej kompilacji.	`BUILD_ID`	`BUILD_BUILDID`
Adres URL, który wyświetla dzienniki kompilacji.	`BUILD_URL`	Ta wartość nie jest ustawiana jako zmienna środowiskowa w usłudze Azure Pipelines, ale można ją uzyskać z innych zmiennych. ¹
Nazwa maszyny uruchomionej w bieżącej kompilacji.	`NODE_NAME`	`AGENT_NAME`
Nazwa tego projektu lub definicji kompilacji.	`JOB_NAME`	`RELEASE_DEFINITIONNAME`
Do identyfikacji kompilacji używa się ciągu znaków; numer kompilacji jest dobrym unikatowym identyfikatorem.	`BUILD_TAG`	`BUILD_BUILDNUMBER`
Adres URL hosta wykonującego kompilację.	`JENKINS_URL`	`SYSTEM_TEAMFOUNDATIONCOLLECTIONURI`
Unikatowy identyfikator funkcji wykonawczej kompilacji lub agenta kompilacji, który jest obecnie uruchomiony.	`EXECUTOR_NUMBER`	`AGENT_NAME`
Lokalizacja wyewidencjonowanych źródeł.	`WORKSPACE`	`BUILD_SOURCESDIRECTORY`
Identyfikator zatwierdzenia Git odpowiadający wersji tworzonego oprogramowania.	`GIT_COMMIT`	`BUILD_SOURCEVERSION`
Ścieżka do repozytorium Git w usłudze GitHub, usłudze Azure Repos lub innego dostawcy repozytorium.	`GIT_URL`	`BUILD_REPOSITORY_URI`
Tworzona gałąź Git.	`GIT_BRANCH`	`BUILD_SOURCEBRANCH`

¹ Aby uzyskać adres URL, który wyświetla dzienniki kompilacji w usłudze Azure Pipelines, połącz następujące zmienne środowiskowe w tym formacie:

${SYSTEM_TEAMFOUNDATIONCOLLECTIONURI}/${SYSTEM_TEAMPROJECT}/_build/results?buildId=${BUILD_BUILDID}

Zarządzanie sukcesami i porażkami

Narzędzie Jenkins umożliwia uruchamianie poleceń po zakończeniu budowy, korzystając z sekcji potoku post. Można określić polecenia uruchamiane, gdy kompilacja zakończy się pomyślnie (przy użyciu sekcji success), gdy zakończy się niepowodzeniem (przy użyciu sekcji failure) lub zawsze (przy użyciu sekcji always). Przykład:

Jenkinsfile

post {
    always {
        echo "The build has finished"
    }
    success {
        echo "The build succeeded"
    }
    failure {
        echo "The build failed"
    }
}

Podobnie usługa Azure Pipelines ma bogatą strukturę wykonywania warunkowego, która umożliwia uruchamianie zadania lub kroków zadania na podstawie wielu warunków, w tym powodzenia lub niepowodzenia potoku.

Aby emulować instrukcje warunkowe Jenkins post-build, można zdefiniować zadania uruchamiane na podstawie warunków always(), succeeded() lub failed().

azure-pipelines.yml

jobs:
- job: always
  steps:
  - script: echo "The build has finished"
    condition: always()

- job: success
  steps:
  - script: echo "The build succeeded"
    condition: succeeded()

- job: failed
  steps:
  - script: echo "The build failed"
    condition: failed()

Uwaga / Notatka

Usługa Jenkins obsługuje dodatkowe post warunki wykraczające poza always, successi failure:

changed: działa tylko wtedy, gdy bieżące uruchomienie potoku ma inny status zakończenia niż poprzednie uruchomienie.
fixed: działa tylko wtedy, gdy bieżący przebieg zakończy się pomyślnie, a poprzedni przebieg zakończył się niepowodzeniem lub był niestabilny.
unstable: Działa tylko wtedy, gdy bieżące uruchomienie potoku ma stan "niestabilny" (zazwyczaj spowodowany błędami testów).
cleanup: Działa po ocenie wszystkich innych warunków końcowych, niezależnie od stanu Pipeline.

W usłudze Azure Pipelines można osiągnąć podobną funkcjonalność przy użyciu warunków z wyrażeniami, takimi jak eq(variables['Agent.JobStatus'], 'SucceededWithIssues') w przypadku niestabilnych kompilacji.

Ponadto można połączyć inne warunki, takie jak możliwość uruchamiania zadania w zależności od powodzenia lub niepowodzenia pojedynczego zadania, zmiennych środowiskowych lub środowiska wykonawczego, w celu utworzenia zaawansowanego potoku wykonawczego.

Obsługa poświadczeń

Narzędzie Jenkins udostępnia credentials() pomocnik w environment dyrektywie w celu bezpiecznego wstrzykiwania poświadczeń do potoku. Usługa Jenkins obsługuje kilka typów poświadczeń, w tym tekst tajny, pary nazwy użytkownika/hasła i pliki wpisów tajnych.

Jenkinsfile

pipeline {
    agent any
    environment {
        AWS_ACCESS_KEY_ID     = credentials('aws-access-key-id')
        AWS_SECRET_ACCESS_KEY = credentials('aws-secret-access-key')
    }
    stages {
        stage('Deploy') {
            steps {
                sh 'aws s3 ls'
            }
        }
    }
}

W Azure Pipelines można zarządzać tajnymi przy użyciu grup zmiennych, integracji z Azure Key Vault lub przez definiowanie zmiennych tajnych bezpośrednio w potoku.

azure-pipelines.yml

variables:
- group: my-aws-credentials  # Variable group linked to Azure Key Vault or containing secrets

jobs:
- job: Deploy
  steps:
  - script: aws s3 ls
    env:
      AWS_ACCESS_KEY_ID: $(AWS_ACCESS_KEY_ID)
      AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY)

Można również bezpośrednio odnosić się do sekretów z Azure Key Vault, używając zadania AzureKeyVault@2:

steps:
- task: AzureKeyVault@2
  inputs:
    azureSubscription: 'my-azure-subscription'
    KeyVaultName: 'my-key-vault'
    SecretsFilter: 'AWS-ACCESS-KEY-ID,AWS-SECRET-ACCESS-KEY'
- script: aws s3 ls
  env:
    AWS_ACCESS_KEY_ID: $(AWS-ACCESS-KEY-ID)
    AWS_SECRET_ACCESS_KEY: $(AWS-SECRET-ACCESS-KEY)

Opinia

Czy ta strona była pomocna?

Last updated on 2026-01-16

Udostępnij za pośrednictwem

Migrowanie z usługi Jenkins do usługi Azure Pipelines

Konfiguracja

Kompilacje oparte na kontenerach

Wybór agenta

Wybór hostowanego agenta

Wybór agenta lokalnego

Zmienne środowiskowe

Wstępnie zdefiniowane zmienne

Zarządzanie sukcesami i porażkami

Obsługa poświadczeń

Opinia

Dodatkowe zasoby