If you are developing software, never mind if it is open source on GitHub or inside a customer project, you have a good understanding of merging and branching. As long as you work alone, all is fine. As soon as you start working in a team’s and you still want to stay friends after the project, you might need to use more than task-tracking on Azure DevOps.
Without build support on Azure DevOps
Inside a project, usually multiple colleagues are working on several components of the system. In best case, they have their own feature branch to commit the changes. Of cause they will test, whatever has been modified regarding the current requirement. Maybe they add a total new component or they just add some lines in the existing code.
Their part is working and they commit the changes. Done.
Really done? I would say no. Of cause it was working on their machine and probably the changes are also fulfilling the requirement. But what, if they missed to add a component to the source control and it is not possible to build it on another machine or some of the unit tests are failing, because the developer just run his own tests? This is frustrating for the next colleague to make changes on that code, because he would need to fix it before he can start working.
The answer on this is the Feedback-build.
Before you can start introducing a feedback build, I would suggest to make the following changes to your current process:
Probably you are creating branches already. Start creating them in a specific sub-folder instead of having them on the same level as master, release or development. Git supports folder. Start creating your feature-branches always in a specific sub-folder. In my case I call that folder “features”. So all the feature branches will be below that folder.
You can create a new branch simply from the Azure DevOps UI or also from Visual Studio itself. Just navigate to Repos –> Branches and use the ‘…’ behind the branch you want to branch from and click on ‘+ New Branch’. Enter as Name “features/myfeature”.
In this case you will create a new folder called “features” automatically.
If possible I also strongly recommend to write some unit tests. Especially for Plugins and Workflow-Activities this makes fully sense. If you have written a test for the most important business requirements, you will be sure, you didn’t broke anything with your code change.
You can use any testing framework, that is supported by Azure DevOps, which literally means nearly anyone. I have chosen xUnit for myself. In some cases I also use FakeXrmEasy to execute the Plug in logic against an in-memory Dynamics.
With these pre-requisites in place, we are now ready to setup our feedback build. Of cause it also works without the unit tests, but having them in place is another level of quality you reach.
Setup your first Build
In your Azure DevOps environment and inside your project, navigate to “Pipelines –> Builds” and click “New Build Pipeline”. You can choose for the beginning the “Visual Designer”.
On the next screen, “Team project”, “Repository” and “Default branch” should be preselected. Change them if you want need.
Final screen is about selecting a template. I always start with an “empty job”, but you can also use “.NET Desktop” and remove any task you don’t want.
Now you end up in the Editor. Main thing is, that you have to give it a name and assign an agent pool. There are some default agent pools you can choose from, but the performance is not the best. If you really want to run them fast, I suggest to host a custom agent.
Now you first build has a name, and will run on an agent of your choice. but nothing more. Save it the first time.
Create the needed tasks
If I need to setup a feedback build, I use the following 4 Tasks:
NuGet Tool Installer
Here I want to have the latest NuGet version running, but also don’t want to loose caching to speed it up. So enter as version number 4.x. This will make sure, you always get the latest NuGet version used fitting that version.
This task is used to restore your NuGet packages for your desired project. Select the command “restore” and also the path to your solution file.
Visual Studio Build
Now it is time to build. You need to select the Solution to build, the Visual Studio version you want to use, the platform and the configuration. You can move platform and configuration into variables, if not, use these values:
platform = any cpu
configuration = release
Visual Studio Tests
Finally I strongly recommend to have the test task included. Depending on your test framework, the configuration will be different. In my case I have used xUnit.
The triggers will make sure, the build is running on each commit against a specific branch. Remember, we wanted to run it on all feature branches. Navigate to triggers and enable the continuous integration. In this scenario we build all commits into any feature-branch, but only, if something in the workflow-folder changed.
Inside the options, you can configure the version numbering. For feedback builds I am using a longer more readable version. This will be used in the e-mails later as well.
You can also enable, that on each failed build the system should automatically create a bug and assign it to the person who triggered it.
After these steps you have configured your first build. I hope you and your team is enjoying the feedback build and is getting more productive. In the next article, I will show you how to create a development build and how you synchronize the configuration between the source control environment and your development environment.