.Net Development, Azure, DevOps, Ideas and Life...

During a recent review of a client's Azure application and part of a Digital Transformation requirement the lights came on for us all after a simple whiteboarding session. Often when technical concepts are being explained, it is difficult to visualise the primary building blocks and interactions of a system at a high level. After just a few minutes at the whiteboard we were able to quickly confirm our understanding of the existing solution and effectively contribute to a plan of next steps to support the transformation process going forward and detail some business and technical requirements. Another tool that can really help to take white board sketches to a new level is Sketch2Code which transforms a hand-written user interface design into valid working wire-frame. It is a web based app that captures the whiteboard image and converts it to a usable HTML prototype. The benefits of this type of approach are great because each and every stakeholder is able to add real

Managing whether an identity has access to a given  service, feature, function, object, or method in Azure DevOps comes down to authorisation. Fortunately, by default, the DevOps permissions are set in such a way to enable you to focus on the job at hand, DevOps. Loosely translated this means 'don't get in my way'. My experience is that the Azure DevOps team have done a good job at this, enabling you to crack on developing, building, testing and releasing without much hindrance. Working with relaxed permissions is great when you are the owner and possibly either a one man band or small team but as soon as we need to consider larger teams, varying roles with approvals and degrees of access, authorisation becomes a real concern. I was recently involved in a project utilising offshore developers where trust was a concern and a number of specific teams handling specific roles needed to come together to approve a set of pipelines.  This article is a pick of findings a