I usually start by creating an organization project at https://dev.azure.com/, then turn over the backlog to the business side of the house with a model of Epic – Features – Tasks, with the tasks being entered by the developers. I work with the business team to create a good overall definition of done for tasks, so the developers will understand how things are considered complete. I then create a repository for code, usually in Git, as I prefer the overall process of code merging. This does come with the caveat of the team understanding the process of PRing code and how to fetch the latest code changes before checking in to help minimize the collisions in code check in. Earlier, I included how the backlog looks, but let's look at how we get to the rest of the project setup. When you log in to the DevOps portal (https://dev.azure.com), you will need to select your organization and the project within that organization, as you can see in the following screenshot:

Once you select the project, you will then see the Azure DevOps menu structure and we need to create a repository for the code. I usually try to keep my repositories as small and as manageable as I can, only placing code needed. I use NuGet for shared code and third party libraries to simply dependencies. As you can see here, in the following diagram, create your repository or repositories needed to support the code development:

I generally use HTTPS for Windows-based machines and SSH for Linux-based machines for repository cloning. For those who don't know, cloning is creating a local copy of the only repository and branching is create a working copy of the code to work on. The code being worked on will use a pull request or PR to merge the code back into the CI main branch. This helps so that you can have an extra set of eyes to review the code by a different team member before it is checked in, formerly called a code review. The PR process includes a build and an automated run of unit testing, then the merge happens.

Once your code repository in main is updated with a PR, your release pipeline should take over and build, then release your code to your development integration environment. This release or future releases can be released to QA or production with the same targeted build by either a manual/automated release with approvals. Let's see how a build would look, shown here in the following diagram:

Once the builds are completed, you can now build out your release, as you can see in the following diagram. Now, I would like to note that there is not a one size fits all for pipelines, as they should contain all the necessary pieces to deploy an application:

So at the end of the day, I like my builds and releases to be phased, meaning I run the infrastructure part, the code deploys part, then the tests. I like to ensure I build out my PR and CI build process upfront as well, as my release process to automatically deploy at least to my development integration environment.