Opsætning af pipeline i et projekt

Denne vejledning bruges ved både nye projekter og overgang fra en eksisterende pipeline. Du skal have et Bitbucket-repository med Pipelines aktiveret, tilgængelige pipeline-minutter og adgang til repository- og deployment-variabler. Ecreos centrale scripts skal være publiceret.

1. Hent den relevante template

Opret en arbejdsbranch i projektets repository. Hvis projektet allerede har bitbucket-pipelines.yml, så gem en kopi før download. Kommandoerne overskriver filen.

Umbraco Cloud:

curl -sSfL https://ecreociscripts.blob.core.windows.net/ci-scripts/bitbucket-pipelines.umbraco-cloud.yml -o bitbucket-pipelines.yml

Azure Web Apps:

curl -sSfL https://ecreociscripts.blob.core.windows.net/ci-scripts/bitbucket-pipelines.azure-web-apps.yml -o bitbucket-pipelines.yml

Hver pipeline henter selv runneren og grupperne ved kørsel. Du skal ikke kopiere de centrale scripts ind i projektet.

2. Opret projektets standardværdier

mkdir -p devops
curl -sSfL https://ecreociscripts.blob.core.windows.net/ci-scripts/devops.env.example -o devops/.env

Har projektet allerede devops/.env, så sammenlign med eksempel-filen i stedet for at overskrive den.

Tilpas især stien til webprojektet:

WEB_PROJECT_DIR="MyProject/Presentation/Website"
SOLUTION_ROOT_DIR=""

SOLUTION_ROOT_DIR kan være tom, når solution-filen ligger i repositoryets rod. Sæt eksempelvis værdien til src, hvis solution-filen ligger dér. En tom devops/.env er også tilladt, hvis de nødvendige værdier kommer fra pipeline-argumenter eller miljøet.

Filen må kun indeholde ikke-følsomme standardværdier og skal have gyldig Bash-syntaks. Gem API-nøgler og passwords som sikrede variabler i Bitbucket.

3. Ignorér runtime-filer i Git

Tilføj følgende til .gitignore:

devops/temp/
devops/output/

Runneren bruger devops/temp/ til midlertidige filer og delt tilstand. devops/output/ indeholder logs og andre pipeline-artifacts.

4. Opret variabler og deployment-miljøer

Følg Variabler og miljøer. Opret miljøerne test, staging og production, hvis projektet skal bruge alle tre. Navnene skal passe til deployment: i YAML-filen.

For Umbraco Cloud skal projekt-id og API-nøgle være tilgængelige. Sæt TARGET_ENVIRONMENT på hvert deployment-miljø til det faktiske Cloud-alias.

For Azure skal hvert deployment-miljø have sin egen Kudu URL, sit deployment-brugernavn og sit password.

5. Gennemgå grupper og branchvalg

Behold setup som første gruppe. Deployment-valideringen skal stå umiddelbart efter, så manglende adgangsoplysninger opdages før build.

Standardforløbet for Umbraco Cloud er:

setup → validate-umbraco-cloud-setup → sync → validate-frontend → build-frontend → validate-dotnet → deploy-umbraco-cloud

Standardforløbet for Azure er:

setup → validate-azure-web-app-setup → validate-frontend → build-frontend → validate-dotnet → deploy-azure-web-app

Tilpas grupperne til projektet. Fjern eksempelvis build-frontend, hvis der ikke er et frontend-build. Beholder du gruppen, kræver den package-lock.json og et build-script i WEB_PROJECT_DIR.

Automatisk deployment bruger som standard main til Test, staging til Staging og live til Production. Kontrollér denne mapping, før du merger pipeline-opsætningen. Se Daglig brug og deployment for andre branchnavne og deaktivering af automatisk deployment.

6. Test opsætningen

1. Commit pipeline-filen, devops/.env, .gitignore og eventuelle lokale scripts til din arbejdsbranch.
2. Opret en pull request. PR-pipelinen skal køre setup og validate.
3. Kontrollér PR-loggen og de tilgængelige artifacts.
4. Når opsætningen er godkendt, merge til den valgte deployment-branch. Med standardmapping udløser merge til main deployment til Test.
5. Kontrollér, at det rigtige deployment-miljø og den rigtige destination bruges, og at applikationen virker efter deployment.

En vellykket PR-validering kontrollerer build og tests. Den afprøver ikke deployment-adgangsoplysningerne, fordi deployment-grupperne først kører ved deployment.

Overgang fra en eksisterende pipeline

Sammenlign den nye template med projektets nuværende fil. Flyt nødvendige projekttilpasninger med, og gennemgå lokale overrides. Et lokalt script med samme navn som et centralt script erstatter stadig den centrale version.

Kontrollér især image, gruppernes rækkefølge, pipeline-argumenter, deployment-navne og branchvalg. Bevar templatenes push-triggers, og undgå samtidig at tilføje branches- eller default-deployment-selektorer. De kan udløse ekstra kørsler sammen med triggers.

Næste side: Variabler og miljøer.