Azure DevOps is being recognised more and more for its contribution in allowing teams to provide quality output more frequently and transparently. Microsoft have even finally released the long awaited PowerApps builder tools as well as a strategy for D365 Application Life-Cycle Management to help with the continuous build and deployment of power platform applications.
When I first used Azure DevOps, it was known then as TFS (Team Foundation Services). We used it as a source control tool mainly. Requirements and test cases were created and maintained in excel spreadsheets. Deployment guides were created for manual deployments. This was all quite normal… The need to provide traceability and streamline our development process led to the investigation of TFS and thus my love affair of DevOps began.
I’m aware that there are people like me at various stages and on different paths of their DevOps journey. To that end, the aim of this blog is to introduce a new series of blogs documenting key considerations I’ve learned when creating a DevOps implementation and encourage discussions around these areas.
Each blog in this series will be categorised by one of three main categories.
People: Discussing the culture and adoption of DevOps and designing DevOps for a modern delivery team.
Process: Discussing the standard processes provided by DevOps and how it fits with existing methodologies. How DevOps can be modified to allow for custom methodologies.
Technology: Discussing the different D365 technologies which can be used with DevOps. e.g. D365 Portals, D365 Finance and Operations and D365 Customer Engagement
Follow my blog to be notified of my first post in this series. Coming Soon!