we've got a GitLab CI build / test / deployment pipeline and need to insert a manual approval between deployment to Test and promoting to Prod. I can't figure out how to do that.
Ideally we would like to have a button like in GoCD or in AWS CodePipeline. However for our current project we use GitLab EE (ver 12.3.5-ee) hosted on our servers, not using gitlab.com, but I guess the .gitlab-ci.yml should be the same.
This is a part of my current .gitlab-ci.yml:
stages:
# lint, build, test, ...
- deploy_test
- approval
- deploy_prod
deploy_test:
stage: deploy_test
only:
refs:
- prod
script:
...
wait_for_approval:
stage: approval
# how do I do this???
deploy_prod:
stage: deploy_prod
only:
refs:
- prod
script:
...
Any idea?
Use when: manual in your stage.
To be sure the manual action is blocking (and no optionnal), add also allow_failure: false (is set to true by default)
More info in the documentation
Note : if you created the stage only for the approval, I could advice you to remove it and put the when: manual in the deploy_prod stage.
deally we would like to have a button like in GoCD or in AWS CodePipeline
In addition, of when:manual, you also have GitLab 14.9 (March 2022), which comes with (still for GitLab Premium/Ultimate only):
Deployment Approval on the Environments page
We are excited to introduce the Deployment Approval capability in the GitLab interface. In GitLab 14.8, we introduced the ability to approve deployments via the API.
Now, deployment approvers can view a pending deployment and approve or reject it conveniently directly in the Environments page. This update continues our work to enable teams to create workflows for approving software to go to production or other protected environments.
With this update, we are now upgrading the feature to beta.
See Documentation and Issue.
And GitLab 14.10 (April 2022) comes with:
Multiple approval rules for deployment approvals API
Previously, deployment approvals supported a simple model where the ability to execute a deployment and approve a deployment were both controlled with a single list of users.
With this update, you have more flexibility and granularity with these rules and can specify multiple levels of control using the API.
One type of model that can now be supported is where there is separation of duties between deployment executors and approvers in your organization.
Another supported model is where approval is needed separately from multiple levels, such as a QA tester group and a security group.
See Documentation and Issue.
You can combine that with GitLab 15.2 (July 2022) which adds (non-CE editions only):
Group-level UI for protected environment settings
Previously, if you wanted to configure group-level settings for protected environments, you had to use the API.
With this release, you can now view and edit these settings in the UI.
This change allows you to more easily set policies for which users and groups can deploy to environments across projects within a group.
See Documentation and Issue.
Related
I've been looking into Azure DevOps and I'm puzzled by something: Microsoft seem to be strongly recommending the use of YAML pipelines instead of classic ones; fair enough, but they need to replace all the functionality that was in classic pipelines. How am I meant to replace the "release pipeline" functionality with YAML pipelines?
So for example, with classic release pipelines, I could setup a pipeline to deploy to production that had a manual trigger (see 'Manually by a user'):
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops#pull-request-triggers
What's the YAML pipeline equivalent to this? I obviously don't want a trigger that automatically deploys to production - I always want that deployment to be initiated strictly manually - but the help article doesn't seem to provide any YAML alternative.
As Daniel comments above, Yaml pipeline supports multi-stage yaml pipelines for CD. You can check Azure DevOps Pipelines – Multi-Stage Pipelines and YAML for Continuous Delivery for more details.
Azure devops yaml multi-stage pipeline and classic release pipeline can both be used for CD, however they do have some difference. And as I know no feature in YAML pipeline can be equivalent to the manual trigger in Classic Release.
For now the manual trigger is not supported in YAML pipeline, see this discussion. Good news is that the Product team has considered the feature request and the new feature is on Roadmap. (Perhaps on plan for 2020 Q3)
According to the team there: The scope of new feature they are thinking here is to be able to mark a stage as "always start manually". If there are other stages that depend on this stage, then those would continue to wait till this stage has executed.
We may have to wait for some time before the manual trigger feature comes true in Yaml pipeline. Hope the new feature would meet your needs.
Microsoft says that their teams internally use Release Flow branching strategy: Release Flow: How We Do Branching on the VSTS Team
Release Flow means that the release branch has to be created to make the release triggered, which can look this way:
releases/productname-sprint02
Therefore, creation of a such branch can act as the manual trigger
In multi-stage YAML pipeline the production deployment stage should be coded to be triggered when the pipeline execution is the release branch context, which is not hard to do using a condition: and an expression that contains a check:
${{ startsWith(variables['Build.SourceBranch'], 'refs/heads/releases')
p.s. My recent blog on the similar subject: Azure DevOps – YAML pipelines and branching strategies
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'm trying pipelines in git lab community edition.
For what I can understand, from gitlab, the code and pipelines live in the same git repository.
In my scenario the pipelines are responsibility of devops team and code from develop team.
How, in git lab, is possible to prevent developers of changing the pipeline?
I understand it's possible to add devops team as maintainer to review pull requests, but this will create a dependency of devops teams in every change.
thanks
GitLab is not really designed for the scenario you describe. The general idea is that developers look after the CI configuration themselves.
You could try using the includes feature to store the bulk of the CI configuration in a separate repository.
In the application repository you would have a .gitlab-ci.yml file that pulls the CI configuration in from another repository using include-project:
include:
- project: 'my-group/my-ciproject'
ref: master
file: '/ci/.gitlab-ci-myappproject.yml'
Then in the my-group/my-ciproject repository you would have a file .gitlab-ci-myappproject.yml that contains the GitLab CI jobs configuration.
build:
script:
- dobuild
Only the DevOps team would have access to the my-group/my-ciproject repository so developers can't edit the CI config (although could mess with the .gitlab-ci.yml` file in the app repository).
Alternatively you could protect the master branch and have all changes approved before merging to master. Then developers would not be able to make changes to the CI without an approval.
I have two sites set up in Azure, a staging site and a production site.
Both sites are connected to the master branch of my git repository.
The stage site gets automatically updated when I commit a change to the master branch. What I'd like to do is have production set up so that it won't automatically be updated, but I can manually update it when I want to.
Basically so that changes will get pushed to stage, and when I'm ready for them to go to production, I can manually push them.
Is there a way to do that in Azure?
You have a couple of options:
Use a separate branch to deploy to production. For example a release branch. When you commit to the release branch, production will be deployed. This way you decide when will be deployed to production.
Another option, which is a bit more work. (especially if you have not done it before), but has it's advantages because of more control over the deployment:
Create a VSTS account in Azure. In the VSTS account create a project. Setup a build against your source to create artifacts which can be used in release management. Create a release which can deploy to Staging, and for example after a approval to production. (It's also possible to configure a swap here if you like, to release to producton)
For information about this:
https://www.visualstudio.com/en-us/docs/build/apps/aspnet/aspnet4-to-azure
https://www.visualstudio.com/en-us/docs/build/apps/cd/deploy-webdeploy-webapps