Multiple Projects and One Solution - DevOps Best Practice

Question

For example, I have the one solution and multiple projects. To be basic, the multiple projects are:

• Solution
  • REST API Web Application
  • Admin UI Web Application
  • Shared Libraries

If I want to have an Azure DevOps pipeline for the REST API and the Admin UI, what would be the best approach?

1. If anything changed in the solution, trigger build for everything and deploy BOTH web apps
2. CI / CD triggers for each deployable project; ie. if only UI change in Admin UI, then only build for that happens

I like #2. I am thinking that if only REST API changes, then only REST API will trigger CI / CD for itself. If Admin UI changes, only CI / CD for it triggers. If Shared Libraries is changed, both CI / CD triggers.

I believe this can be done using Path Filters as trigger. However, what if in the future I have a new Shared Library2? I would need to edit the Pipeline trigger for that new project. So I am not sure anymore if this is good practice (might forget to add the trigger?)

Answer 1

To answer your question on best practice it would be breaking the deployment in such a way to minimize potential impact while also ensuring functionality within reason while also ensuring a consistent integration and quality stream of code.

I'd recommended combining the approaches if you want to maintain control over both scenarios. This can be accomplished by breaking each deployment into it's own stage and then tie that stage to an environment that requires approval. For Dev would recommend doing a full CD to catch anything that might fail and then approvals on your additional environments. Your pipeline would could look like:

Build Stage:

• Build and publish REST API Web Application
• Build and publish Admin UI Web Application
• Build and publish Shared Libraries

Deploy Rest API Stage [Dev]

• Job to deploy API

Deploy Admin UI Web Stage [Dev]

• Job to deploy UI

Deploy Shared Libraries Stage [Dev]

• Job to deploy Shared Libraries

Deploy Rest API Stage [UAT]...

Deploy Admin UI Web Stage [UAT]...

Deploy Shared Libraries Stage [UAT]..

Do this pattern for each environment and have the environment approval be configured. This would allow for a complete Deployment in Dev every time w/o approvals and in additional environments the ability to approve which deployments are needed. Additional if doing multiple geos/instances can call that out in the jobs for that stage to allow for scalability of the different components. In addition the jobs and tasks could be templatized to optimize reusability and reduce copy and paste.

Also if doing this would highly recommend using YAML Templates as this would allow you to define the jobs/steps needed for a stage once and reuse.

Here is how to set up environment approval

Here is how to look at configuring stage templates