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.)
Related
I'm facing the following issue: I have one git repo with a Node.js application. The application is divided into several components, namely: server, client, microserviceA, microserviceB. There is also a directory named shared with some sharaed code used by all the other components.
I have a pipeline for each of the components that only runs tests, which run on pull-request to master. Each pipeline only runs when the PR contains changes relevant to him, e.g. server-ci will run only when there were changes in the server component, etc.
Now, on merge to master, I would like to build the components and deploy them on a staging server. Currently what I have is as follows: for each component (beside the shared) I have another build pipeline (<component>-build) which on merge to master builds the corresponding component (depending on the changes made, as above). I have one Release pipeline which takes as artifacts all these build pipelines and deploys them on the staging server. So the good thing about this is that merge to master which includes only changes in client will build only client and not all the rest of the components.
The problem is, that on merge to master that contains changes to several components, I'll have more than one build pipeline running, so they will both trigger the Release pipeline. This is not desirable.
A possible solution I thought about was, to have only one build pipeline which runs on merge to master, but then I'd have to build ALL the components on each merge, which is inefficient.
What is the best way to deal with such situation?
In the release stage settings you can configure that Number of parallel deployments will be 1:
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 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.
So I have a application split in 4 different repositories which all have their own Azure Pipeline build. But the artifacts of these 4 builds are deployed in one release (into one application).
On a check-in (pull request merge) on our development branch in one of the repos, a build for that repo is started. When this build completes, a release is triggered with the newly finished build artifact + 3 older artifacts based on the "Latest from the build pipeline default branch with tags" from the other repos. So always the latest builds from the development (dev) branch.
Now we want to also deploy an environment for every pull request that is created in the different repos, so our business can test a pull request.
I have the release pipeline done (the actual deploying of the environment), but not sure how to select the artifacts correctly. After a build on a pull request branch, I need to start a release with the pull request artifacts from that triggering build + the latest dev branch artifacts from the other 3 builds.
Manually I can start a new release, by default it selects all the dev artifacts, but by hand I can select the correct artifacts for the PR branch and start a correct deployment. But I want to automate (trigger) this.
How can I configure this automated trigger? Could I use tags? Or am I thinking about this in a wrong way?
Edit
I ended up setting this up by using 4 different stages which have different artifact filters. A stage for each artifact. For that artifact we allow dev_* and all other artifacts need to be from dev_. That way the correct stage is triggered for each artifact trigger, selecting the feature branch and dev branch for others.
It is not the ideal solution, because it does require some duplication of code, but by using Task Groups I have been able to minimize this. But for now I don't see a better solution.
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.