Author: Arad

Make your EF Query logs traceable

If you are a .NET developer, there is high chance that you’ve spent way too much time looking at Entity Framework logs to understand and investigate generated queries. Probably one of the most time-consuming tasks is to find out what has been translated to what especially when it comes to complex chatty solutions. Entity Framework Core 2.2 introduced a new feature called Query Tags which can be used to tag queries and make the output traceable. You simply can annotate your LINQ queries using TagWith() method.

Let’s have a look at an example. In the following example, I annotated my query with “List of top 10 books”:

var books =
      (from b in DbContext.Books.TagWith(@"List of top 10 books")
      orderby b.Price descending
      select b).Take(10).ToList();

And here is the query output in the the log:

-- List of top 10 books
 
SELECT TOP(@__p_1) [b].[Id], [b].[Name], [b].[Price]
FROM [Books] AS [b]
ORDER BY [b].[Price] DESC

Now as a developer, I can easily find out my query output in logs without burning calories!

Stop doing “DO NOT MERGE” pull requests

You probably have been in a situation where you finished your task and ready to create a pull request, but for whatever reason you don’t want your changes to get through (For example, you want to merge your changes back into the main branch after the current release). A common behavior – or let’s say old fashioned way – is to put something like “DO NOT MERGE” or “WORK IN PROGRESS” in the pull request’s title. And as an unwritten rule you should write it in all caps :). In such a situation, you can draft a pull request instead of creating a pull request.

To Draft a Pull Request in Azure Repos, you need to choose “Create as draft” when you want to create a pull request.

If you look at the list of pull requests now, you will see your pull request marked with “Draft” token.

Share your Azure Boards status with Status Badge

Microsoft introduced a new feature in Azure Boards called “Status Badge” which summaries your board status in a git-style badge and allows you to share it in your docs and dashboards.

You can find this new feature in your board settings under Status Badge.

Status Badge

Check “allow anonymous users to access this status badge” checkbox if you want to share your badge with anonymous users.

New “Basic” Process available in Azure Boards

Microsoft introduced a new process in Azure Boards called “Basic“. Now Azure DevOps supports four different templates to address different team size and projects with different needs and processes. New “Basic” process is very similar to github issue concept.

What does the world look like in Basic mode?

It’s all about simplicity. It just makes the process very simple and takes the heavy-planning-and-backlog-management bits out of the equation. If you are not maintaining an extensive multi-layer portfolio backlog where delivery must be tracked in different levels (and you probably have couple of cross functional teams), then “Basic” is for you.

You have a three-level hierarchy of ‘Epics”, “Issues” and “Tasks”. Technically speaking, everything is an Issue. If you are familiar with “Agile” or “Scrum” templates in Azure DevOps, an Issue is equivalent to a “User Story” or “Product Backlog Item (PBI)” or “Bug”. You’ve heard it right, there is no such a thing like Bug item. An issue is what you and your team need to deal with – it can be a bug investigation, bug fixing, feature development or a code improvement. You can breakdown an issue to some small tasks (this is usually done by developers) and then track your tasks as usual. Epic comes into the picture when you want to group couple of issues as a deliverable.

Is “Basic” for me?

First, lets’ look at the summary of all templates:

Agile:
This process is great if you want to use Agile methodologies to execute the project. You should choose Agile template if you want to track “User Stories” and “Bugs” on the Kanban board. This is recommended if you want to deliver a User Story from requirement gathering and design to coding, testing and deployment in one “iteration”. You manage your portfolio backlog through “Features” and “Epics” in this template.

Scrum:
Choose Scrum process if you want to use Scrum practices to plan and execute the project. Using Scrum template you can track “Product Backlog Items” and “Bugs” on the Kanban board. You manage and track your portfolio backlog through “Features” and “Epics”.

CMMI:
You should choose CMMI if you want to have auditable record of decisions and change requests. Using CMMI template you have to manage “Requirements” at backlog level and “Features” and “Epics” at portfolio backlog level. “Change Requests”, “Issues”, “Risks” and “Reviews” are other types of work item in this template.

Basic:
You should choose Basic if you don’t want to manage your portfolio backlog extensively and you see “Epic” as a deliverable. in this template you only have “Issues” to track your feature development and bugs.

Basic is a right fit for you if you are not into complex processes. It may not be scalable enough when it comes to big teams and complex plannings and executions. In both Scrum and Agile you can plot out complex delivery and feature road maps, while basic by nature is not really suitable for long-term multi-level planning where sometime you need to track the progress of a deliverable across couple of sprints or even (Hopefully not!) releases.

Bypass branch policy in Azure Repos

It’s a good practice to lock down your repo and put some branch policies in place to avoid merging unwanted codes and non-complaint branches and commits into your master branch. However, we’ve all been in that situation where something urgently needs a fix and for some reasons we can’t meet the branch policies. By using Azure Repos, you can give a special permission to a set of users to override and bypass branch policies when things are on fire.

Azure Repos allows your lead developers to bypass branch policies when they want to push code or complete a pull request when it’s needed. You just need to set the settings in your repo settings. Navigate to your repo’s security setting, select the group and role your super users belong to and set the bypass policies’s settings.

azure-repos-set-permission-to-bypass-branch-policies

CI/CD/CT at Enterprise Scale – Categorize Your Tests

moren-hsu-359121-unsplash
Photo by: moren hsu

When it comes to enterprise software, you usually have to deal with huge number of tests (I hope that’s the case for you!). One of the biggest challenges in having an efficient CI/CD/CT pipeline is to have a small set of tests to run to make the integration and deployment faster. One of the techniques to reduce the testing time is to limit the testing scope. I previously post a blog about Test Impact Analysis here which is one of the most reliable ways to trim the testing scope but also by categorizing your tests you can achieve small test surface even in development environment. Remember if you expect developers to run ten thousand tests before committing the code that will never happen!

Using TestCategory lets you create a group of tests using any arbitrary system you want (i.e. Domain, Scenarios etc.). This gives you an opportunity to create and run related tests together to facilitate the testing in CI/CD/CT pipeline. The only thing you need to do is to annotate your tests with TestCategory attribute.


[TestMethod]
[TestCategory("Aircraft")]
public void GetAllAircraft()

You can even assign a test to multiple category. If you want to filter your tests in Visual Studio by category you need to switch to list view in Test Explorer and then filter tests using Group By toggle.

CI/CD/CT at Enterprise Scale – Add label to Pull Requests

As a best practice, when we want to merge  a topic or feature branch back into the main branch we create a pull request. Developers sometimes may need to communicate some extra information with reviewers or bring their attention to specific details. In VSTS, labels provide a new way of communication for pull request.

You can tag your pull requests with labels like “Hotfix” or “Dependency” or even “DON’T MERGE” and draw reviewer attention to an important details.  Nowadays, many teams communicate things like this during the stand-ups or even through communication tools like Slack or Microsoft Team. However, when it comes to enterprise level app and big teams, traditional ways are not really practical because communications can easily get lost between team members.