A couple years back I wrote a tutorial on how to highlight blocked work items on an Azure DevOps sprint board (here). This post is a similar walkthrough but describes the process for overdue and due soon work items.
Providing a visual highlight for these items is a great way for the development team and product owners to quickly see which work is considered time sensitive and potentially overdue.
Note: These changes do not require any extensions, but they do require project collection administrator access rights to complete.
This post is the second in a two part series on React JS. The first post covered design decisions to make before starting a project, and this post provides tips for building and deploying React web applications in Microsoft Azure with Azure Pipelines.
In this post we will do a complete walkthrough for configuring a new continuous integration (CI) pipeline that builds PowerShell modules in Azure DevOps Pipelines. Formalizing your PowerShell build steps into a CI pipeline helps enforce code quality standards and setup a fully automated process for publishing.
I have covered some of these pieces individually in other posts; for example my module starter kit and linting configurations. However a full post is helpful to tie all the pieces together in a detailed guide.
In Google’s Site Reliability Engineering book, the chapter on toil (tedious, manual operational work) asserts that we should keep toil work amounts to only a small fraction of our total engineering hours. The reason for this is that too much toil work negatively impacts the engineering team.
In this post we will review some toil basics, talk about why toil tracking matters, and see how we can leverage Azure DevOps to track and classify our sprint work for enhanced toil budget tracking.