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.
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.
I followed this article to learn about staging environments https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots. What are the code changes required in order to set up staging environments in Azure App Service?
What makes you think code changes are required? A staging slot is in its essence it is just a deployment target.
That said, the one thing I can think of is making sure your application does not contain hardcoded configuration that is different between test and prod environments.
If the ARM template is well parameterized it won't need any changes too. The build pipeline should be able to deploy to multiple environments (dev/test, prod etc) by supplying different parameters to the template.
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?
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.
My source code is on GitHub.
I have an Azure Devops pipeline set up to build and deploy the application to an Azure subscription.
I also have the full azure environment defined in ARM templates.
I'd like to run the template deployment only when a specific folder changes in my GitHub repo.
Path triggers are only for Azure Devops repos.
Other possible solutions I investigated, but there is no clear documentation on how to achieve this exactly:
Custom condition on build or release task.
Pre-deployment conditions. Maybe artifact filters?
Pre-deployment Gates?
The ARM template deployment is idempotent, I know, but it takes a several long minutes to run even if there was no infrastructure change and I'd like to avoid that time wasted on every build.
Sounds like you have a single pipeline for both the infrastructure and application code. I have separate pipelines for each, one for infrastructure as code and other builds/pipelines for applications, NuGet package creation, etc. Perhaps split the pipeline and have the application deployment trigger after and separately from the infrastructure deployment pipeline. That way the application build and deployment can run in a more frequent cycle.