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.
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
Heroku and Gitlab have Preview Apps as part of their CI/CD pipeline. Which is great for trunk based development as you get to test the branch in an isolated environment before merging the PR to master. Is there a way to do this in Azure DevOps? Could you use a custom Agent for this? How would you do that?
Our stack has React (client), .NET Core (api), MS SQL Server (storage). What I would like to add to our CI/CD pipeline is Preview App which can be used as QA step and we could also run our E2E Cypress tests against it.
Currently our devs have to run E2E tests locally as part of our PR process. For QA step we have to merge the PR to the master so that it will get deployed to our development server. Since QA works against our master branch we are forced to use release branches. After QA approves the merged PR, it's then cherry-picked to release branch. Release branches are then build and deployed automatically.
I would like to add QA step to our PR process so that we could deploy straight from master. Now we get it done, but I would like to streamline the process even more.
We have dozens of code repositories in Azure DevOps, and we're working on a major release strategy.
We have a stable development branch called develop, where code has been tested and peer-reviewed, with features approved by QA. All of our service repositories have a similar structure.
We want to "click a button" and branch from develop across all our repositories to a release candidate branch, that QA can regression test as a complete system... basically a "snapshot" of what we expect is ready for release. We would then build from this code base, release to our QA environment from the corresponding builds, and when certified, deploy to production, then smoke test and merge the release candidate branch into master, then master back into develop.
It doesn't seem like there's an easy way to manage multiple builds or releases in Azure DevOps though. Atlassian's Bamboo supported this concept of "meta builds" but I don't see a way to do this in Azure DevOps. I can't seem to even create a build that is not implicitly linked to a single repository.
How can I automate this and get this workflow working in Azure DevOps?
You can use a Build Task from the Marketplace that queue a new build: the first two found are Trigger Build Task and Build Chain.
You defined an overarching build that queues the single ones and does any additional work.
Using the Delivery Pipeline service, I'd like to deploy my artifacts to staging/QA environments where QA/Product team members can test features/defect fixes before those changes get merged into Production branch.
How would I spin up these temporary testing environments when pull requests are created?
There is currently no way to build off of pull requests. One option would be to have a separate branch that people can merge code into. You can then have a build stage which builds that branch and a deploy stage to deploy to your staging/qa environment. You can then have another stage will does the merge into the production branch. (Note, this stage should only be triggered manually.)