Using multi project pipelines I want to run a specific job. Under deploy I have CI - PVT - Staging - Prod
I wish to deploy from a separate project simply Deploy Staging none of the other deploy stages.
I do have a paid for Gitlab so triggering etc. is enabled.
Is this possible please?
Related
New to Automation- I have created a automation cypress project in my local. I pushed the project to Azure dev ops and created a pipeline for that. The test cases are running successfully. My question is Dev team wants to trigger those test cases before deploying the build. How to achieve that? Anybody can help, thanks a lot!!
My question is Dev team wants to trigger those test cases before
deploying the build? How to achieve that?
You can make use of Stages to trigger your Cypress tests in the Dev stage first and then start the next deployment in your Build stage manually. You can start the deployment in any stage or across stages manually one after another or automatically in one run.
I created one sample cypress task in my Azure Pipelines like below:-
Now, I ran the pipeline in a Dev stage first like below and then at Build, You can trigger these pipelines together automatically or one by one manually, Dev team can run this pipeline before triggering it in the Build stage:-
Save this release pipeline and Trigger the required build stage manually with the below option:-
Here, you can select both your Dev and Build stage to trigger manually by yourself. With the above option Dev will run automatically and Build should be run manually like below:-
After the Dev stage is triggered the Build stage can be triggered manually like below:-
Reference:-
Stages in Azure Pipelines - Azure Pipelines | Microsoft Learn
Cypress in Azure DevOps Pipeline | Azure DevOps Pipeline | azure pipeline cypress | cypress test case azure | Medium
Need help in designing CI/CD pipeline for deploying the Dynamic-365 solution in different environment.
Present set up CI/CD configuration:
we have 4 BU’s, where each BU has separated Azure DevOps project pipeline to deploy the solution in different environment.
Build pipeline is designed to export solution from dev environment and push the artifact in to azure repo.
Release pipeline is designed to import solution and publish the solution in destination environment.
I am looking for one master pipeline design which will help us in deploying the all 4 BU’s solution but it has to deploy in different environment for all 4 BU’s. Is this possible? How can I design such a pipeline? or else any other pipeline configuration which help up in achieving this?
I have an application with .NET Core web API and Angular client application which is hosted in Azure as app services. Trying to introduce full DevOps practice to this up until production.
I'm trying to create a release pipeline in Azure DevOps while keeping git-flow as my branching strategy. currently,
I have 5 different environments which are Dev > QA > UAT > Pre-Prod > PRODUCTION.
I know with a trunk-based approach this is pretty easy to configure with one release pipeline which will go through all the environments as one release until it goes to production. In the current setup, this is automated only up to the UAT environment using Only the Development branch as the release pipeline which works pretty well.
I'm wondering what would be the most suitable way to do it keeping git-flow as my branching strategy. Also, relevant branches should automatically tag with UAT and production releases.
Mainly I have a development branch that contains the latest development activities and feature branches will be merged into development after PR approvals and Master is the production equal branch.
With my current environments setup, releasing this to UAT is quite simple with the Development branch but when proceeding to Production it might cause problems.
To keep the question short considering multiple factors, I was planning to have 3 different pipelines as follows
UAT - One release pipeline from development which goes through Dev > QA > UAT
Prod - Master branch will be configured with this pipeline which goes through Pre-Prod > Prod environments. this will be a separate build pipeline which will trigger soon after development merges with the master branch. this will be the main production pipeline. either this could be a master or separate release branch.
Hotfix - This will be the Production hotfix release pipeline with a separate build pipeline which goes through QA > Pre-Prod > Prod.
Will this approach works or any bettor way of doing this. Since this is the very first time planning release it to production through the pipeline. I would like to hear advice from experts?
I want to be able to run automated tests from within Azure Test Plans and define everything in a yml file.
What I've done:
I have a repository in azure DevOps containing several tests written in .NET core. Those are associated to a testcase in azure test plans.
I also have created a azure pipeline by adding a .yml file to my repo. This pipeline consists of two stages, one for the build and one which actually runs all tests on a nightly schedule.
However, I want the manual testers to be able to trigger the automated tests from within Azure Test Plans too. The official docs say one must create a release pipeline to do so. So my questions are:
Why do I need a release pipeline? I already have my build pipeline, I won't do any release, I just want to be able to run my tests from within test plans by button click.
If I really have to create release pipeline, how can i define this in a yml file? The official docs only mention the "Classic", manual steps within azure DevOps, but I don't want to add pipelines manually, I want to have everything defined in yml files.
Is there a possibility to run my tests containerized? I do it already in my build pipeline, but since I couldn't find a way to define release pipelines in yml, I don't know how to run them in docker containers.
Azure Pipelines offers a compelling orchestration workflow to obtain test binaries as artifacts and run tests. This workflow shares the same concepts used in the scheduled testing workflow, meaning users running tests in scheduled workflow will find it easy adapt; for example, by cloning an existing scheduled testing release pipeline.
Another major benefit is the availability of a rich set of tasks catalog that enable a range of activates to be performed before and after running tests. Examples include preparing and cleaning test data, creating and cleaning configuration files, and more.
To define release pipeline in yml, you should go to the preview features page and turn on the toggle for “Multi-stage pipelines”.
Below is a simple sample.
stages:
- stage: Build
jobs:
- job: Build
pool:
vmImage: 'Ubuntu-16.04'
continueOnError: true
steps:
- script: echo my first build job
- stage: Deploy
jobs:
# track deployments on the environment
- deployment: DeployWeb
pool:
vmImage: 'Ubuntu-16.04'
# creates an environment if it doesn’t exist
environment: 'smarthotel-dev'
strategy:
# default deployment strategy
runOnce:
deploy:
steps:
- script: echo my first deployment
More detailed information, you can refer to https://devblogs.microsoft.com/devops/whats-new-with-azure-pipelines/
I am learning CI/CD concepts and trying to set up a pipe line in Azure to deploy my sample api to dev, int,qa and prod environments. I was able to deployment the build successfully to all environments. But what is the correct way of doing CI/CD in the companies? We cannot have build on every check-in to all environments even though we have the unit testing run in the build. The usual flow should be Unit test then deploy to Stage/QA and once QA signs off then we promote the build to PROD right? How does this fit into the CI/CD pipeline? Also we can have multiple builds in Dev, can we select which build to deploy to stg and prod?
The ideal way would be to link each of your check-ins to some bug/task so that it will be linked to appropriate test case .After the check in automated test cases are run simultaneously and test whether the check in is valid. If it is valid you can line it up to deployment which only will be deployed after getting the necessary approvals.It is recommended to run continuous integration pipeline to each check in so that you will have a history of build success and failures which is a big relief when you have to find/track errors.
To the prod environment you have multiple approvals as requirement to deploy and provide all the approvals when the sign off is provided.
For the build to map to stg and prod .yes you can do this .If you are using web app in azure and you have prod and stage slots then you can point the branch to respective slots in the deployment configuration.
Please let me know if you need anything else.
Hope this helps.