trigger configuration imageI want to set up a ci/cd pipeline for my gcp project based on cloud functions service. Right now I am able to deploy to gcp project from cloud build with a trigger when pushing code on the staging branch.
My cloudbuild.yml file looks like this:
steps:
- name: 'gcr.io/cloud-builders/gcloud'
args: ['functions', 'deploy', 'profile', '--region', 'europe-west1', '--trigger-http', '--runtime', 'nodejs8', '--entry-point', 'profile']
dir: functions
After that I created a second gcp project as production environment, to isolate stage and prod environment. I tried to follow the same process with master branch this time. I created the trigger to deploy cloud function when pushing to master just like staging case but it fails to trigger build. Any ideas ?
Related
I currently have a frontend and a backend repo. Each has a simple and basic workflow to test, build and upload the built files to my AWS S3 and AWS ECR. I am comfortable with this current workflow but I wanted to complete my CI/CD pipeline so I also created an IaC repo that creates AWS resources and deploys the latest commit of my frontend and backend repos.
This is the flow for my GitHub Actions:
frontend
On push to master --> test --> build --> upload the build files to AWS S3 --> release
backend
On push to master --> test --> build --> upload image to AWS ECR --> release
My AWS CDK repo (IaC) is triggered manually by myself.
The missing part of my CI/CD pipeline is the trigger to my IaC when either my frontend or backend repo publishes/releases successfully.
I was thinking of either using AWS Codebuild or just doing it all on GitHub Actions (but I don't have a clue where to start).
Background -
I have multiple web service projects under multiple azure repos. All these projects have same structure as they are ASP.NET core web applications. I have written separate yaml pipelines and created separate yaml jobs for each project which has similar steps and placed them in separate azure repos.
Issue -
I have created separate yaml pipeline jobs (multistage - build and deploy) depending on each yaml. Is there any way to consolidate these yaml to one and place to shared azure repo and trigger the pipelines on the code commit to respective azure repos and deploy it to their related environments on azure web services?
Is there any way to consolidate these yaml to one and place to shared azure repo and trigger the pipelines on the code commit to respective azure repos and deploy it to their related environments on azure web services?
The answer is yes.
You could create a new repo with a new YAML file in it, or you could select one repo as main repo and set the YAML with Repository resource:
resources:
repositories:
- repository: A
type: git
name: MyProject/A
ref: main
trigger:
- main
- repository: B
type: git
name: MyProject/B
ref: release
trigger:
- main
- release
The best way to manage these is a separate repo as template. Essentially your template contains the pipeline steps that you want to run, and for each pipeline you need you have a yaml file that extends the template by defining what triggers you want for that pipeline and pass any pipeline dependant parameters you are using to the template.
Templates
I am setting up CI/CD at work and there is one step I’m not sure how to do and furthermore, if it is a right thing do.
For background, I am used to develop in C# with Visual Studio, source code in TFS and deploying with basic script that copies files on the intranet.
Now, I’m requested to setup Build and Release pipelines on Dot Net Core projects in GitHub.
I have three branches on this project: DEV, RELEASE and MASTER
I created one pipeline that triggers on DEV’s commits, creates an artefact and deploy to DEV server.
Those are the pipelines that deploy all developers work to a DEV server where they run their own tests.
Next step, when we want to deploy to staging servers, we click a button in Azure, this merge the DEV branch to the RELEASE branch but I know close to nothing in GitHub, not even sure those are the appropriate words.
When the merge is done, this will trigger a build pipeline that will create a different artefact, when this artefact is updated, deploy to staging server.
Once this release is validated on Staging and Quality, we would merge RELEASE to MASTER and do the same until PROD servers. It is all on intranet and self-hosted agents.
Is that a good way of doing things? Can it be done this way? I need a PowerShell task or is there something that exists?
If you are using Azure DevOps pipeline, the pipeline should select GitHub for repository type, then we can configure the CI trigger.
a. Configure CI trigger:
Classic steps:
1.Open project setting->Service connections->select GitHub-> create a new GitHub service connection
2.Create a new build pipeline via classic editor-> Select GitHub as the source.
3.Open pipeline->select the tab Triggers-> enable the option Enable continuous integration and configure the Branch filters
b.YAML steps:
1.Open project setting->Service connections->select GitHub-> create a new GitHub service connection
2.Create a new build pipeline and select GitHub(YAML)
c.The sample of Check out GitHub repositories in your pipeline
resources:
repositories:
- repository: MyGitHubRepo # The name used to reference this repository in the checkout step
type: github
endpoint: MyGitHubServiceConnection
name: MyGitHubOrgOrUser/MyGitHubRepo
trigger:
- {branch name}
Configure CD trigger:
Please refer to this doc to configure the release trigger.
If you are using GitHub action.
Please select the correct workflow to configure the CI/CD, Please refer this doc for more details
CI sample:
on:
push:
branches:
- ' DEV'
Update1
When Dev branch is updated, it is built and deployed to Dev server by pipeline.
Create build A and release B, configure the CI build trigger, when the branch Dev is updated, it triggers the build pipeline A, and when build pipeline A is completed, it triggers the release pipeline B.
click a button to synchronize Dev branch to Release branch.
We cannot see the button, as a workaround, we can add task powershell and call the API to create pull request and complete the pull request. We also can add task cmd and publish the code via git cmd
I'm using Azure DevOps as the source code repo for my Docker containerized Angular application. In the process of creating release pipelines to deploy the code base from dev to test (then to staging and prod) I noticed that after selecting the Azure App Service deployment template, I could not specify a branch for code movement.
For example, I could not specify the dev branch for the pipeline that would move code to the test environment. Does this mean that for containerized apps I have to have separate repos for each environment: dev, test, staging, and prod? Further, does this mean that for code deployment that I would have to move, let's say, code from the master branch in the dev repo to the master branch in the test repo, and so on?
As with any other CI\CD pipeline what happens is the following:
you build your code
you test it
you package it
you release it
I guess you miss the fact that you create an artifact and then you release it to dev > staging > prod. In other words you promote it across environments.
As for moving the code between branches - yes, thats what you have to do anyway. Unless you want your branches to be disconnected completely between each other (which makes very little sense).
I have a multi-container app running with App Service - Web App for Containers. It all works fine as long as the Docker Compose (Preview) configuration is provided under the Container Settings tab.
Currently, I am using Azure DevOps to create builds for specific containers, and then use the Continous Deployment option (in Azure Portal) under Container Settings to pull the latest deployed container image from ACR. This also works fine. I can run builds for individual containers, and deploy only specific container without affecting the web app. (Each container is a separate project, and only has a Dockerfile without requiring docker-compose)
However, when I create a Release from Azure DevOp using Azure App Service Deploy (version 4.*), the Docker Compose (Preview) configuration in Azure Portal is completely wiped out, and it defaults to Single Container and the application breaks. The Docker Compose configuration is needed as it makes the main container aware of the other containers.
I am using version 4.* of Azure App Service Deploy. I would like to use the Release feature of Azure DevOps as it provides more control.
Is there a way I can specify the docker-compose multi-container configuration from Azure App Service Deploy version 4 so that the App Service is aware of the multi-container configuration and not wipe out the multi-container config in Docker Compose (preview)
Thanks,
Karan
Replace the Azure App Service deploy task in your Release pipeline with an Azure Web App for Containers task. There are parameters for multiple images and a configuration file (Docker-Compose.yml).
As Dave mentioned this is possible using the AzureWebAppContainer task, however the documentation does not mention the options regarding multi-container deployment.
I had to dig into the source code of that task to discover the task parameters.
https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/AzureWebAppContainerV1/taskparameters.ts
I'll summarise my setup to give you an idea how it can be used. I have a multi-stage pipeline defined in YAML. There are two stages, the first stage builds and publishes the Docker images and the second stage updates the Web App for Containers app service.
The first stage also produces an artifact, namely the docker-compose.yml file that is used to configure the Web App for Containers app service. In my repository I have a template for this file. During the pipeline execution the tags of the docker images are replaced within this template (e.g. using envsubst or sed). Then the resulting docker-compose.yml file is published as an artifact.
- task: PublishBuildArtifacts#1
displayName: "Publish artifact"
inputs:
pathToPublish: $(Build.SourcesDirectory)/pipelines/assets/docker-compose.yml
artifactName: yml
In the second stage of the pipeline the artifact is downloaded and used to configure the Web App for Containers. In the example below the AzureWebAppContainer is a step of a deployment job.
- task: AzureWebAppContainer#1
displayName: 'Azure Web App for Containers'
inputs:
azureSubscription: '<YOUR_SUBSCRIPTION>'
appName: '<YOUR_WEB_APP_FOR_CONTAINERS>'
multicontainerConfigFile: $(System.ArtifactsDirectory)/yml/docker-compose.yml
The generated docker-compose.yml is stored as an artifact and you can always consult it later.