We have around 13 prod and 13 non-prod environments in multistage YAML pipeline, due to this the performance is very slow. Can we keep prod and non-prod in a separate folder, so that while deploying we can run ci/cd independently.
Please suggest.
Thanks
Can we keep prod and non-prod in a separate folder, so that while deploying we can run ci/cd independently.
If you need to run CI/CD independently, you can split your pipelines into build pipelines and release pipelines.
Build pipelines automate test and build for your project. Release pipelines delivery automatically deploy and test code in multiple stages to help drive quality.
If your issue is that the application is deployed to all environments, then as Krzysztof Madej commented, you can modify your pipeline to deploy to one or more of them.
Related
I am getting started with CI/CD and experimenting with Azure Pipelines and my NodeJS project.
I have 3 environments Dev, UAT and PROD.
As I understand it in Azure you have Pipelines for the CI and Releases for the CD.
Is it best practice to run the build (npm build) part of the the project in the Pipeline when creating the Artifact or in the Releases stage, when deploying?
I'm conflicted from the research I've done, as it seems the benefit of an Artifact is the same code is used across the whole CI/CD Pipeline in all environments, removing any probability of repo based differences. However when in Dev one might want to run the project in development mode, which may introduce its own environment based differences and this is environment dependent, so should be run in the Release stage.
A single deployment at my organization might involve running half a dozen different pipelines.
Some of these pipelines are classic "Release" pipelines. Some of these are modern yaml pipelines.
Sometimes these pipelines need to run sequentially. Sometimes they can run in parallel.
Is there any way in Azure DevOps (Server 2020) that I can group these together so that I can deploy the whole set with one command?
We have been converting our Release pipelines in Azure DevOps to instead be YAML files that run as Pipelines. This is so we can store our deployment process as code. The deployment process is working well - so a developer commits code and the Pipeline builds and publishes the artifact in one stage and then it auto-deploys to the QA environment in another stage. Subsequent stages deploy to an Environment (e.g. QA, Staging, Production) each of which requires some approval(s). The deployments themselves aren't the issue.
What I'm struggling with is unlike the old Releases there isn't a dashboard that will tell me which version of the project is in each environment. The Pipeline summary represents each stage for the Run as a dot (running, succeeded, failed, canceled, etc.) but wasn't built to represent what each environment has (probably because a stage doesn't have to be a deployment).
Is there somewhere else I can look for this information or do I have to build my own dashboard by calling the AzDO APIs? Looking at the Environment gives a list and I can root through the history, but that's not the experience our developers are looking for.
We are planning to implement CI/CD for our project. In summary, our setup is the following:
Code Repository (contains solution and project files)
Config Repository (contains .config files for different countries)
Aside from having multiple environments, we also have instances in multiple countries. Sample below:
Country 1
Dev
QA
Prod
Country 2
Dev
QA
Prod
I understand that Azure Release Pipelines can have multiple Stages (Dev, QA, Prod) and Variables that can be used for deployment. Then we can have a 1 Release Pipeline for each country.
What I am having difficulty is the Config Repository. Sometimes, developers may need to update a specific config file for a Country for a specific environment.
The only solution I can think of is trigger a release pipeline with this again, but just to replace the Web.config on IIS in the VM.
However, this is not good, because if developers only update Code Repository, any changes from Config Repository will be overwritten.
Any suggestions on how to automate multiple countries / environments with pipelines?
Thank you
Hi you can use Azure DevOps Environments to target environment strategy (in your case country and Dev/QA/Prod)
Normal practice shouldn't using repository for .config and any settings files.
you can also consider using Secure files for Azure Pipeline or inline script (within your environment deplyonce)
you can start exploring that Azure Pipeline Environment to understand it and YAML and how can it apply to you Multi-Stage YAML.
We have been using a YAML file to do our CI in Azure DevOps for a few months with the idea that we would get our release configured using YAML in the future.
Well that time is now and I'm confused by how you would introduce a CD process. With the MyProject-CI.yml being a Build Pipeline and our Releases being Classic Pipelines I assumed that when the time came to get the CD process down as YAML we would create a MyProject-CD.yml. That would be triggered by the dropping of an Artifact within the MyProject-CI.yml CI.
However I think that was just a misunderstanding on my behalf and what we are supposed to do is convert the original MyProject-CI.yml into a multi-stage pipeline that has the following stages
Build and Run Unit Tests
Deploy to Development and run WebTests
Deploy to Production and run WebTests
Is the switch to a multi stage CI/CD in one file correct rtaher than Release and Build in separate files?
The short answer is yes, you got the idea. A single multi-stage pipeline yml is the way to do both build and deploy, and that is the base intention. Here is an exercise that parallels your case that might help.
As your pipelines get more complex, you will likely get into scenarios with multiple files, as you can template parts of your pipeline for reuse in multiple places, or to enforce conventions from a central location.