Customizing ADO

This article is for the basic process template. The hierarchy is Epic, Issue and Task. Each level in this hierarchy has a page. Keep in mind that page follows a 3 section layout, Detail, Planning and Related work.

Epic customization Click on three dots (…) on the right side in Epic.

This will show following page;

Click on New field. You will get to following page;

The frequently used fields are already listed in “Use an existing field” but if you want to create a new one, you can use “Create a field”.  More important, on the left side of navigation, pay attention to Layout section. This is where you can decide where to store this field; left, center or right.

Some standard fields that can be used in these pages are;

Risk, Effort, Business Value, Start Date, Target Date, T-shirt sizing, Story points, Activity, Original Estimate, Remaining Work, Completed Work.

Resources

https://learn.microsoft.com/en-us/azure/devops/organizations/?view=azure-devops

https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/customize-process-work-item-type?view=azure-devops#what-you-can-customize

Simplifying ADO.NET Code in .NET 6

When developers think of how to access data, many use the Entity Framework (EF), Dapper, NHibernate, or some other object-relational mapper (ORM). Each of these ORMs use ADO.NET to submit their SQL queries to the back-end database. So, why do many developers use ORMs instead of just using ADO.NET directly? Simply put, ORMs allow you to write. If each of these ORMs are simply wrappers around ADO.NET, can you write your own wrapper to cut down the amount of code you need to write? Absolutely! This series of articles shows you how to create a set of reusable wrapper classes to make it simpler to work with ADO.NET in .NET 6.

Read more on CodeMag web site here;

Simplifying ADO.NET Code in .NET 6: Part 1

Simplifying ADO.NET Code in .NET 6: Part II (Coming soon)

Standard Practice to Create Repository

A standard practice to create repository should always be;

  1. Main branch should always have a .gitignore and readme file.
  2. Create a working branch from main
  3. Develop feature in your working branch
  4. Before committing, do a merge from remote main to working branch and resolve any conflicts in working branch. This will help you to get team changes merged into your working branch.
  5. Commit your changes. Create a PR and you are done.

I hope this will help.

How to add gitignore file in existing solution using Visual Studio

Stop tracking the files that should be ignored in Git

How to add gitignore file in existing solution using Visual Studio

Recently I came across an issue where existing projects were showing .vs folder checked-in and being tracked. Developers were having code conflict problems and were not able to create PR request.

Here is the work around to add gitignore file in existing solution using Visual Studio.

Remove .vs folder from main branch and working branch. If there are PR policy in place, disable that for fixing this. After .vs folder removal, enable PR policy.

Open Visual Studio and make sure it’s connected to Git branch. Click on Git->Settings.

This will add gitignore file in the root of project folder. Switch to Git changes window in your working branch and commit / sync your changes.

Now we need to stop tracking all .vs folder changes that’s been created on developer machines to build and run the project. Use these magic commands, one time only;

git rm -r –cached .
git add .
git commit -am “remove ignored files”

For added piece of mind, sync your main branch and do a merge from main branch to work branch locally. Resolve any cache files and conflicts. You might need to run above three command again.

After this, Create PR and it should merge with main branch. This will take your pain away.

I hope this will help.

Standard Practice to Create Repository

Stop tracking the files that should be ignored in Git