Gitlab has a notion of environments. I'd like to define a deployment stage for production, but only allow to run it, if the same commit has been deployed successfully in staging. Is this best done in one pipeline with prod jobs after staging or is there some way to define a dependency for environments?
Since you can:
view environments and their associated deployments
query a specific environment
I would make as a first step of my deployment stage for production one that queries the staging environment, get the deployable/commit id associated to that environment (part of the JSON answer), and compare it with the commit being deployed to production.
If that does not match, the pipeline would stop immediately in error.
Related
As written deploy pipelines can be pushed manually. I want to know if there is a way to stop the deploy from happening unless all pervious stages are done.
For example if I push deploy on Production, the Production deploy should check that Dev, Test, and Pre-Prod completed successfully before continuing.
I looked at deploy gates, but there does not seem to be anything in there for this condition.
I am actually surprised this is not part of the tool design. As written out of the box someone can push a deploy to Prod even if Dev, Test, and Pre-Prod aren't completed at all.
Does Microsoft just want us to rely on approvers to eyeball the situation? I am not sure how to constrain deploys for this particular condition.
You can link the stages together, so that the deployment happens first on dev, and only if that succeeds it will go to pre-prod, and then prod.
However, even with stage dependencies, I think you can still deploy at any stage at any time directly. To have more safeguards, you can add a script to your deployment steps that will check that previous steps are completed using Azure DevOps API.
We are currently facing a conundrum with our multi-tenant project which contains various configuration files for each of our tenants and their associated environment. Our CI/CD Pipeline is split into two parts
An Upstream pipeline which analyses the new commit to master to
determine which tenants/environments have been changed. This triggers
the downstream pipeline with the correct environment variables via
the API
A downstream pipeline which executes scripts to deploy
changes to the tenants' environment based on the environment variables
passed through. This works well, however we have a Gitlab Runner per
environment to access the customers environment. We use this to avoid
hard-coding multiple credentials within our scripts or CI environment
variables.
Is there a way we can trigger this downstream pipeline with the specific Gitlab Runner? Our Gitlab Runners are tagged per environment so that we can use the passed environment variables to detect which runner it should be ran on.
I’ve had a look around the Gitlab CI, specific runners and shared runners (which ours are currently) but doesn’t seem to be supported.
tags: supports variable expansion. So, it is possible to pass variables in the API call when creating your downstream pipelines in order to control which runners are used.
I am implementing azure devOps in Azure Data Factory.
My development environment ADF is integrated to a git repository.
I have created a build pipeline for building artifacts when there is a change in adf_publish branch.
My next step is to deploy the ARM template artifact to the PROD environment.
Suppose there are many triggered pipelines in the PROD environment and few pipelines were running in the PROD env at the time when the DEV changes are getting deployed to PROD.
My questions are:
How the changes are deployed from DevOps to PROD environment? Will it delete and replace all the pipelines and triggers from DevOps or It will pick only the changes and update the PROD env without touching the unchanged pipelines?
Suppose a pipeline is running in PROD env at the time of deployment, what will happen to that pipeline run?
Suppose there is a triggered pipeline at 3:00 O clock and deployment starts at 2:55 and ends at 3:05. What will happen to that triggered pipeline which was supposed to run at 3:00?
Any one having a clear idea about above questions or Is there any documentation for reference to obtain answers for these questions?
I have gone through Keeping deployment mode as Incremental instead of keeping it as Complete at the time of ARM template deployment. Will that option do all the tasks which I asked above?
How the changes are deployed from DevOps to PROD environment? Will it delete and replace all the pipelines and triggers from DevOps or It will pick only the changes and update the PROD env without touching the unchanged pipelines?
It depends on the deployment mode you choose.
Deployment Mode: This specifies the deployment mode in which the Azure resources specified in the template have to be deployed.
Incremental mode handles deployments as incremental updates to the
resource group . It leaves unchanged resources that exist in the
resource group but are not specified in the template. Complete mode
deletes resources that are not in your template. Validate mode
enables you to find syntactical problems with the template before
creating actual resources. By default, incremental mode is used.
Suppose a pipeline is running in PROD env at the time of deployment,
what will happen to that pipeline run?
Your deployment will fail, and you may receive a 409 conflict error message. You could check the document Best practices for CI/CD：
Pre- and post-deployment script. Before the Resource Manager
deployment step in CI/CD, you need to complete certain tasks, like
stopping and restarting triggers and performing cleanup. We recommend
that you use PowerShell scripts before and after the deployment task.
For more information, see Update active triggers. The data factory
team has provided a script to use located at the bottom of this page.
Suppose there is a triggered pipeline at 3:00 O clock and deployment
starts at 2:55 and ends at 3:05. What will happen to that triggered
pipeline which was supposed to run at 3:00?
Similar to your second question, the pipeline should not be triggered (or in the pending state), but I still don't have an instance to test such a scenario.
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 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.