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.
Related
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 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.
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.
I'm using Azure DevOps as the source code repo for my Docker containerized Angular application. In the process of creating release pipelines to deploy the code base from dev to test (then to staging and prod) I noticed that after selecting the Azure App Service deployment template, I could not specify a branch for code movement.
For example, I could not specify the dev branch for the pipeline that would move code to the test environment. Does this mean that for containerized apps I have to have separate repos for each environment: dev, test, staging, and prod? Further, does this mean that for code deployment that I would have to move, let's say, code from the master branch in the dev repo to the master branch in the test repo, and so on?
As with any other CI\CD pipeline what happens is the following:
you build your code
you test it
you package it
you release it
I guess you miss the fact that you create an artifact and then you release it to dev > staging > prod. In other words you promote it across environments.
As for moving the code between branches - yes, thats what you have to do anyway. Unless you want your branches to be disconnected completely between each other (which makes very little sense).
We have dozens of code repositories in Azure DevOps, and we're working on a major release strategy.
We have a stable development branch called develop, where code has been tested and peer-reviewed, with features approved by QA. All of our service repositories have a similar structure.
We want to "click a button" and branch from develop across all our repositories to a release candidate branch, that QA can regression test as a complete system... basically a "snapshot" of what we expect is ready for release. We would then build from this code base, release to our QA environment from the corresponding builds, and when certified, deploy to production, then smoke test and merge the release candidate branch into master, then master back into develop.
It doesn't seem like there's an easy way to manage multiple builds or releases in Azure DevOps though. Atlassian's Bamboo supported this concept of "meta builds" but I don't see a way to do this in Azure DevOps. I can't seem to even create a build that is not implicitly linked to a single repository.
How can I automate this and get this workflow working in Azure DevOps?
You can use a Build Task from the Marketplace that queue a new build: the first two found are Trigger Build Task and Build Chain.
You defined an overarching build that queues the single ones and does any additional work.