Getting started with Azure Devops -create a build pipeline -Part 2 (Classic Editor)

This is part 6 of a multipart series on getting started with Azure DevOps. Please refer to the below links to access other notes in this series.
Part 1: Getting started with Azure DevOps
Part 2: Getting started with Azure DevOps -work items
Part 3: Getting started with Azure DevOps -add a repo
Part 4: Getting started with Azure DevOps -create a build agent
Part 5: Getting started with Azure DevOps -create a build pipeline -Part 1 (YAML pipeline)
Part 6: Getting started with Azure DevOps -create a build pipeline -Part 2 (Classic Editor) (this note)
Part 7: Getting started with Azure DevOps -create a deployment group
Part 8: Getting started with Azure DevOps -create a release definition
In my previous note, I discussed the approach to create a pipeline using YAML and why that’s the way forward. Picking up from where I left, here I discussed the process to create a pipeline using the old fashion classic editor. Like I mentioned earlier, this is the approach I have used extensively at work and am familiar with and hence stated that YAML is the way forward. There are some good reasons (that I mention in my previous note) for projects to migrate out of the classic editor based approach.

Step 1: Getting back to the pipeline tab under Azure DevOps project we see that here too (like in YAML pipeline), we start with selecting our repo.

Step 2: …followed by a template.

There are a considerable number of template available, however, I started with an empty job. That way I can build the pipeline and keep it as clean and light as required.

Step 3: The first thing that we define in a pipeline is the Agent pool. An Agent pool is a group of machine/s where we build/compile our product. In the case of Azure DevOps services we get to choose whether we prefer Azure Pipelines (hosted) or Private (our own). I listed the steps in a separate blog on how to create your build agent here.

What we choose here determines where our code gets compiled/built. If there are no dependencies on third-party software that need to be installed on an agent, proceeding with Azure Pipelines (hosted) makes sense because that’s one less system to manage.

Step 4: After that, we selected the location of our code repository

Here, we also set whether we want the build folder to clean (preferred) its local folder each time a build is requested and whether to label sources (preferred) with each build.

Step 5: We then move to agent jobs. This is where we add the tasks that are required to get our code compiled and packaged. Click on the + next to Agent job to bring up the options available

I added the tasks that were performed sequentially based on our product’s build and package logic. Here is an example of a set of build jobs for Azure web apps for ASP.NET

Step 6: We can also choose what trigger we set to kick start the pipeline. A few basic options to set here would be: (i) set the path filter, (ii) continuous integration, and (iii) batch changes checked so that we’re aware of whether our check-ins/commits are causing any build failure.

We can also set the build-pipeline to be triggered on a certain schedule or when another build completes.

Once all the build settings were finalized, I saved and ran the build-pipeline to review if all settings were correct and if the build passed.

And, those are the steps to create a build pipeline in the classic editor.

The difference from the YAML approach is that when we save this build-pipeline it does not get stored (commit/check-in) into the same repo. And that is where its limitation arises. Keeping code and the build-pipeline in the same repo is beneficial (as I discussed in Part 1 of this 2 part article). The other difference from a YAML approach is support for task groups -classic editor supports task groups while YAML does not. In the classic editor world, task groups reduce a lot of overhead when multiple build definitions need to consume an identical change.
That brings us to the question -why would we (continue to) use the classic editor?
Answer: I think users will continue with the classic editor for projects and build-pipelines that use task groups and have existed before the YAML based approach was released. 
Conclusion:
For new projects that are being started in Azure Repos using the GIT framework, I think the right choice is YAML pipelines. The learning curve might be steep, but it is worth spending time familiarizing with because of the long-term productivity and traceability benefit that we derive.

Next, Part 7: Getting started with Azure DevOps -create a deployment group