According to Microsoft. ADF will create the adf_publish branch that contain the ARM template. If I have 3 environment: DEV, UAT and PROD. And 2 items of work: A and B. Both of them are developed in DEV and merged to master and published afterward.
From adf_publish I will then deploy the UAT for testing purposes. What if item A is passed the UAT, B is not and I only want to deploy item A into next PROD release. Do I have to create another branch from DEV to eliminate B, merge to master and re-deploy to DEV/UAT/PROD again? Please view this
Context.
In case of Azure data factory, release pipeline will take ARM templates from adf_publish branch and then deploy them directly in to different environments. ARM templates will be generated in adf_publish branch when you actually publish changes to DEV ADF after your PR.
Hence, it will good if you can plan to execute test cases of UAT also on feature branches itself so that any specific branch related changes of passing your test case then you can avoid PR for that specific branch.
Related
We have a development branch that is fed from feature branches through pull requests. After merge a build occurs and the artifact created triggers the release pipeline with some deployments happening automatically and others happening after manual approval.
After the approval happens for production, and after successful deployment, we would like to merge the PR that was was merge to develop to our main branch. I was wondering if this could be achieved automatically from the pipeline.
Note that not all the PR are going to make its way to production and the latest may not be the one being deployed in production.
Assuming that you must complete the PR to trigger the CI build and release pipelines, you won't be able to re-use the existing PR to merge into another branch because PRs are specific to branches and once completed they can't be re-opened.
In theory, you could add logic to your release pipeline to create a new PR after successfully deploying into production but this is dangerous because PRs are based on branches and not individual commits. So if the develop branch changes while you're deploying into production the new PR would contain changes that haven't been deployed. If you have a small team and the number of PullRequests are low, this might not be a problem for you.
However, if you have a large team and dozens of pull-requests a day, you might benefit by adjusting your a gitflow branching strategy. In that model you would create a release branch and deploy that into other environments. Creating the pull request at the end of that pipeline flow makes total sense because you're deploying and merging a static branch.
For example, you could add a step in your release pipeline to create the PR using the Azure CLI:
$pr = az repos pr create `
--source-branch develop `
--target-branch main `
--title 'merge $(Build.BuildId) into main' |
ConvertFrom-Json
Write-Host 'Created PR $($pr.pullRequestId)'
There's another question where they're doing something similar.
Alternatively, look at the "Github flow" model. They use a trunk-based branching strategy where the PR is king and changes in the PR ultimately go to production or they don't get merged. The GitHub team had a model where they concentrated on a single PR at a time with a flow that looked like:
Designate a PR as a candidate for production
Automation would lock the target branch and create a temporary merge of the PR and the target branch
Automation would build this branch and deploy it to various environments.
Upon successful build into the environment, the automation would unlock the target branch and complete the PR.
It's worth pointing out that Azure DevOps does support triggering Releases from Pull Requests, and each PR-triggered build is a temporary merge of the target branch, so you could create a release and deploy it into your environments with your approval gates. You could add automation to your release to approve the PR:
az repos pr set-vote --id $pr.pullRequestId --vote approve
I am implementing a gitflow workflow with master and development branches, and I have 3 environments: DEV, UAT, PROD.
Using Azure DevOps, when the PR completes and the feature branch is merged into development, I trigger the release to DEV environment.
I am unsure on how to deploy to UAT after that. My first approach was to automate the deployment to UAT after the deployment to DEV succeeded (sequentially, DEV and then UAT), but it doesn't feel right to automate the deployment to UAT.
Should I create another branch for UAT deployments, and automate the deployment to UAT when development merges into that branch?
It's not need to have a branch for each environment. You should promote the artifact, not the source code. A specific branch should be integrated with the CI process, and its artifact should be promoted through each stage until production. The Continuous Delivery pipeline should reflect the environment stages, not the branch model.
A useful blog for your reference:
https://medium.com/#grazibonizi/understading-the-connection-between-branching-models-and-delivery-pipeline-c9cb12e30516
I have a project with two branches (develop and master) and a release process to three environments (dev, staging, production).
I've implemented CI/CD, where the code on develop branch is the code deployed to dev and staging environments. The last step of my release pipeline is deploy to production and I would like to know if there's a way (a task) to check if the code deployed on dev and staging environment is already on master branch.
Thanks
In this case i would suggest you separate dev deployment from the rest, otherwise you will never know if your merge to master was succesful or not, since you never test it. In my opinion the master branch in your case should be the mirror on what is in production.
for your dev build, create a release pipeline which deploys to your dev environment
create another build for the master branch trigered When you merge your dev branch into master. You can use tagging and set a new tag on master, before merging, in order to preserve the old version for hotfixing. and then:
either a new release pipeline with stages staging and Prod
or a new artifact in the previous pipeline with artifact filters for the stages staging and prod
You could also consider changing your branching strategy. In case you develop features and only merge them to your branch, which is deployed to Prod in the end stage, you could use Release Flow branching model with only 1 branch.
The last step of my release pipeline is deploy to production and I
would like to know if there's a way (a task) to check if the code
deployed on dev and staging environment is already on master branch.
For now we don't have any task which is designed to do this kind of job. So there doesn't exist one easy solution to your requirements, you may have to do some changes to your workflow to meet your requirements. Just as the Mario suggests above, you can consider using the Release Flow.
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 am setting a CI/CD pipeline on Azure devops.
This one gets executed when a Build for the master branch is completed.
I was asked to set the stages of the image above, which description is the next one:
Development, QA and Production : Publish the build artifacts on a server (each one).
Testing: Execute some automated test with katalon studio.
My problem is that, when I create a Development branch this pipeline cannot be executed for the build, because the pipeline is just executed when I commit to the master branch, then I create another CI/CD pipeline for Development branch, remove Development stage from Master CI/CD pipeline and incorporate it in this new pipeline.
My question is... is that correct ? , what´s the best estrategy for git branching when you have this kind of pipelines?
My problem is that, when I create a Development branch this pipeline
cannot be executed for the build, because the pipeline is just
executed when I commit to the master branch, then I create another
CI/CD pipeline for Development branch
For this issue, you don't need to do that. You only need to add the Development branch to the Branch filters of Continuous Integration in build Triggers.
Then add the Development branch to the Build branch filters of the Continuous deployment trigger.
After this setting, when you commit to development branch, build and release pipeline will also be triggered.