Scenario

Acme is a successful accountancy firm based in the UK which is currently going through a digital transformation programme of work to modernise its legacy systems using a proper approach for a real digital transformation scenario. As part of the programme, Acme wants to become more “agile” and embrace new approaches and technology to deliver more modern and efficient services to its clients. One of the key components of the transformation programme is an "Integration Platform" that will provide integration between core operational systems. The Integration Platform will provide a scalable messaging layer that offers Acme the ability to decouple applications from each other such that, in the future, changing a system will not require the reimplementation of point-to-point services, but instead the fulfilment of a particular contract with the Integration Platform.

Landscape

As part of its digital transformation programme, Acme has adopted a cloud first strategy and Microsoft Azure is their chosen public cloud.

Acme’s small team of developers are relatively inexperienced in their approaches and in the past have typically only worked in isolation or in pairs to deliver projects with no formal process.

The developers have experience of using .NET Core and React and currently use Azure DevOps for managing their source code.

Architecture

The architecture of the Integration Platform is based around the Message Broker pattern using a “publish and subscribe” model to pass messages from one system (publisher) to another (subscriber).

Components

Component	Description
On-ramp	A set of Azure logic apps and functions that are triggered by an event in a publisher system and send a message to the Message Broker.
Message Broke	An Azure function which is called by an on-ramp process and performs data transformation and enrichment operations on messages before placing them on an Azure service bus
Off-ramp	A set of Azure logic apps and functions that are triggered by a message being placed on an Azure service bus.
Admin	A web application providing administrative and monitoring capabilities for the Integration Platform. The application should be implemented using a React frontend with a .NET Core Web API backend.

Key requirements

• The Architecture team have defined that the platform must use a “serverless” approach by default and use .NET Core for backend functions and APIs.
• Each component should be independently testable and deployable.
• Passwords and/or secrets for production systems must not be stored in source control or in plain text configuration settings.

Explain your view

Please describe how you would approach the delivery of Acme's new integration platform in terms of your proposed:

• approach to managing work items and / progress
• structure of the source code repo(s) and what approach you would take to managing branches
• approach to ensuring code quality is maintained and what tools/frameworks you would use
• development toolset
• approach to managing deployments including the required Azure resources
• approach for managing passwords and secrets
• Benefits to Acme of the approaches above
• Any key risks or assumptions

Digital transformation scenario: what is your approach? My explanation

Proposed approach to managing work items and / progress

In the developer's world, Agile methodology is the common way to manage the work and the workflow. Agile is a practice that promotes continuous iteration of development and testing throughout the software development lifecycle of the project.

Agile - Scrum

The architecture of Agile methodology is based on the same simple steps in a specific period of time. The time is usually 2 weeks and it is called Spring. The main steps are:

• Sprint planning: based on the business input, the team estimates each user story and decide what tasks will be included in the next sprint. Sometimes there is a grooming section separately where the team estimates the tickets, called Poker Plan (an easy online tool is planITpoker)
• Sprint: the period of time, usually 2 weeks, where the team is working on the tasks on the board
• Daily Scrum Meet: every day, usually in the morning, the team is gathered and each person explains what she or he did the day before, if he or she faced issues or any blocker.
• Sprint Review Meet is held at the end of the sprint to inspect the increment and adapt the product backlog if needed
• Sprint Retrospective Meet: the team is talking and analysing how the sprint went and highlighted what went well, wrong and could be improved. An easy free tool online is IdeaBoardz

During the sprint, the team has a board. For each user story, there are one or more tasks to complete. At the beginning of the sprint, all tasks are in the status of new. So, each developer has to peek up one ticket each time: when a developer picks up one ticket, he or she has to change the status of the ticket to Active or In progress. When the developer completes the task, the task is in the status of code completed and then it can be moved in the status of Resolved. The ticket is now ready for tester: testers are responsible to check the functionalities and if the acceptance criteria is satisfied. Then, the task is completed and it is possible to close it and change its status to Complete.

This process has simple steps. Every company can organize the process and the label of this process as it is more convenient.

As developers, Azure DevOps offers a good integrated platform to manage the Agile ceremony. Therefore, there are other tools more business oriented like Jira. In a digital transformation scenario this are important tools to define at the beginning of your approach.

Discriminating Epics, Features and User stories

After that, it is difficult to understand the different among these 3 parts of the process and, apparently, epics, features and user stories are all forms of expressing user need and implied benefit, but at different level of abstraction. While there is no rigorous way to determine whether a "think you know you want to do" is an epic, feature and user story, the following table of discriminators should help:

Type of information	Description	Responsibility	Time frame & Sizing	Expression format	Testable
Strategic Product Theme	BIG, hairy, audacious, game changing, initiatives. Differentiating, and providing competitive advantage.	Portfolio fiduciaries	San strategic planning horizon, 12-28+ months. Not sized, controlled by percentage investment	Any: text, prototype, PPT, video, conversation	No
Epic	Bold, impactful, marketable differentiators	Program and product management, business owners	6-12 months. Sized.	Most any, including prototype, mockup, declarative form or user story canonical form	No
Feature	Short, descriptive, value delivery and benefit oriented statement. Customer and marketing understandable.	Product Manager and Product Owner	Fits in an internal release, divide into incremental sub-features as necessary. Sized in points.	Declarative form or user story canonical form. May be elaborated with system use cases.	Yes
User story	Small atomic. Fit for team and detailed user understanding	Product Owner and Team	Fits in a single iteraion. Sized in story points.	User story canonical form	Yes

Proposed structure of the source code repo(s) and what approach you would take to managing branches

As a developer, I like to have an integrate environment for repositories, deployment and resources such as web app and/or server less applications. For this reason, I’m using Azure DevOps also, because, it is free for unlimited repositories but with limited access (up to 5 users).

For each repository, I’m following a common structure that allows you to manage the master branch, a developer branch, tagged releases and hot fixes. This is Git flow.

In our repository’s structure you have some main folders:

• feature: new tasks are created here
• bug: fix some exists functionalities
• hotfix: fix some bugs in production

In the configuration of the CD/CI, usually, there is a peer to peer review between developers to merge a branch to the develop branch or master. When a new branch is merged in the develop branch, the CD/CI process, automatically prepare the build and start the deployment.

In Agile point of view, each developer is responsible for a single task at the time. For this task, the developer has to create a branch, common practice is to name this branch with the task number plus a short description of the branch in the right folder. For example

feature/511-Login

When the task is completed, the developer has to create a new Pull Request to merge his changes to the develop branch. If the peer to peer review is positive, the branch is merged on develop.

For admin purposes, each branch could be associated with a task in the board. So, when a branch is merged, the correspond task is closed.

Proposed approach to ensuring code quality is maintained and what tools/frameworks you would use

As developer, you know you have to learn constantly: every day new technologies come up, new tools, new environments. The interaction between developers is important because we can teach each other something new.

For this reason, show your code to other developers is always a good way to improve the quality of your code and at the same time to learn something new. Nonetheless, websites like Github are so popular with a lot of users. In your team, peer-to-peer review is the simple way to check your code and find new implementation or structures. To be on the same page, a weekly meetings to share information should have an important impact in your team.

In Visual Studio there is an integrate tools called Code Analysis. The Code Analysis feature of Visual Studio performs static code analysis to help developers identify potential design, globalization, interoperability, performance, security, and a host of other categories of potential problems. Code Analysis can be run manually at any time from within the Visual Studio IDE, or even setup to automatically run as part of a Team Build or check-in policy for Azure DevOps Server.

Linters and Code Analysis

GCop is a fairly new set of C# code analysis rules (with really nice setup, use and rules documentation) from Geeks Ltd., which may be worth checking out if you're not entirely satisfied with other code analysis rulesets (or perhaps using alongside of those other rules for extended coverage). GCop is intended to be installed in your project as a NuGet package. To allow for rules that can't run from a package, Paymon (a co-founder of Geeks Ltd.) has released a GCop.Extra Visual Studio 2017 extension for use with GCop. The extension enables GCop rules such as Minimum Scope that detect whether methods that are more visible than they need to be (private versus internal versus public).

MultiLinter, by Giovanni Lambiase, enables you to replace the (already outdated) linters built into Visual Studio 2017 with the standard linters available through Node.js including (but not limited to) ESLint, JSLint, JSHint, Stylelint, CssLint and Sass-lint. MultiLinter lets you turn verbose debugging on, configure which linters to use (including running multiple linters against a file at the same time), update linters and linting rules, set rule severity warnings, and much more.

XamRight, from Critical Hit Tech, is an extension for Visual Studio 2015 and 2017 that brings design-time code analysis and coding assistance to Xamarin.Forms XAML development. You get IntelliSense, warnings, view model and data binding analysis and debugging, navigation tools for moving between XAML and C# model definitions, custom view implementations and more, along with navigation from XAML resource references to definitions. XamRight can analyze your own model-view model binding, but also includes built-in support for popular MVVM frameworks including MVVMCross, MVVMLight, FreshMVVM, Prism and Caliburn.Micro. A 30-day free trial is available and licensing is available on a monthly or yearly basis.

NDepend, one of the most popular commercial static code analysis tools for .NET Framework development, recently released a substantial update including support for .NET Core 2.1, ubiquitous language checks in Domain Driven Design (DDD), performance improvements for Visual Studio 2017 and over a dozen new or improved code analysis rules. A key new feature for NDepend is real-time technical debt estimation that's updated as you code. Proud of that new method? Guess what, you just added 30 minutes of future technical debt. Maybe check NDepend's analysis and spend a minute refactoring. I love it. NDepend offers a free 14-day trial and per-developer or per-build machine licensing.

Priyanshu Agrawal's Async Method Name Fixer is an effective little tool for doing a simple but often overlooked task: making sure your async methods are named appropriately. In a nutshell, it looks for methods defined as async and, if you haven't given the method a name with "Async" on the end, the extension flags all instances of the method and calls to it.

Code Coverage and Testing

AxoCover, by axodox (Péter Major), provides Visual Studio integration for code coverage and unit testing with OpenCover. AxoCover lets you run, debug and check code coverage for unit tests in .NET Framework projects for Windows. You can browse and analyze coverage by test in a hierarchical view and dig down into line-by-line coverage and test results. AxoCover supports the MSTest, xUnit and NUnit test frameworks.

SmartTests.Extension, by Ludovic Dubois, is an extension to show current and missing tests for NUnit, Xunit and MSTest within Visual Studio. SmartTests.Extension integrates into your Visual Studio environment the Pretty Objects SmartTests library, which helps you write smart unit tests, and the SmartTests.Analyzer, a Roslyn Analyzer to display missing tests as warnings. The extension shows tests in a centralized window, lets you see current tests and any missing tests, and lets you navigate quickly to specific tests.

SmartBear's TestLeft UI test automation framework has been updated to support Visual Studio 2013, 2015 and 2017. TestLeft integrates directly into the Visual Studio development environment, enabling you to create tests as you code. A built-in object spy gives you the ability to create tests that support over 500 common Web and desktop UI controls. You can create automated tests for a variety of popular development frameworks including .NET Framework, Winforms, WPF, Java, HTML5 and AngularJS. Further test coverage includes controls from Infragistics, DevExpress, Syncfusion and Telerik, along with cross-browser testing with legacy versions of Internet Explorer, Edge, Firefox and Chrome. Tests created in TestLeft can be migrated into TestComplete for automated testing as part of your continuous integration and release management processes. Register online for a free 30-day trial. Yearly per-node and floating licenses are available from SmartBear.

Selenium is an umbrella project for a range of tools and libraries that enable and support the automation of web browsers. It provides extensions to emulate user interaction with browsers, a distribution server for scaling browser allocation, and the infrastructure for implementations of the W3C WebDriver specification that lets you write interchangeable code for all major web browsers.

This project is made possible by volunteer contributors who have put in thousands of hours of their own time, and made the source code freely available for anyone to use, enjoy, and improve.

Testing with BDD

Digital transformation could drive you to change approach on testing. Behavior Driven Development (BDD) is an agile software development practice – introduced by Dan North in 2006 – that encourages collaboration between everyone involved in developing software: developers, testers, and business representatives such as product owners or business analysts.

BDD aims to create a shared understanding of how an application should behave by discovering new features based on concrete examples. Key examples are then formalized with natural language following a Given/When/Then structure. 

Gherkin is the most commonly used syntax for describing examples with Given/When/Then in plain text files, called feature files.

Gherkin scenarios can be automated to validate the expected behavior. At this point, BDD tools – such as SpecFlow – come in handy. Automated acceptance tests, however, are an optional by-product of using BDD, not the sole purpose.

SpecFlow is the #1 .NET open source framework for Behavior Driven Development, Acceptance Test Driven Development and Specification by Example. With over 10 million downloads on NuGet, SpecFlow is trusted by teams around the world.

In SpecFlow, specifications are written in plain, simple language which is defined by the Gherkin Syntax (Given-When-Then).

SpecFlow provides a whole ecosystem of tools to use BDD on Azure DevOps and the Microsoft .NET platform. Besides SpecFlow and SpecFlow+Runner, there is also a SpecFlow Visual Studio Extension that provides a Gherkin editor and build integration. SpecMap and SpecFlow+LivingDoc are Azure DevOps extensions that support the team in the overall BDD process with managing their backlog using story maps and accessing their living documentation.

Better Debugging

Angel Hernandez's VisualSOS.Extension gives you access to features of the Microsoft SOS Debugging Extension and Windbg that are not available directly from the Visual Studio Debugger. VisualSOS.Extension also gives you menu access to those features instead of having to remember the commands and option flags. Visual SOS is available as both a Visual Studio 2017 extension and a stand-alone debugger. To learn more, see Hernandez's blog post Visual SOS – Visual Studio extension to debug managed applications through SOS for an overview and some tips for more effective debugging with SOS.

LINQBridgeVs, from Coding Adventures, provides a Custom Debugger Visualizer within Visual Studio that creates a bridge between your Visual Studio debugging session and the external LINQPad scratchpad and test environment. After rebuilding your project, you can right-click on any public classes or structs in the project and open the related debugging data within LINQPad. The extension supports Visual Studio 2012, 2013, 2015 and 2017 along with LINQPad 4 or 5, but is limited to .NET Framework 4.0 and above. Check the documentation for installation and troubleshooting notes.

Microsoft's Visual Studio Live Share, provides a collaborative development environment, enabling you to share code, collaboratively edit, securely share local servers and even collaboratively debug your code in real-time. It's not a screen share service or centralized codebase; you're able to work independently in your local Visual Studio environment while collaborating on code editing and debugging. As we go to press, the VS Live Share is in limited preview: anyone can download the extension, run it and join a session, but permission to share a session requires registration and acceptance into the preview. For more details about VS Live Share including demos, see the Visual Studio Live Share Web site and Visual Studio Live Share Microsoft Docs.

Proposed development toolset

Visual Studio is the main tool for developer and Microsoft releases it in different flavour:

• Visual Studio Community: basic functionalities for developers for creating desktop application, web applications, mobile applications, libraries and much more with .NET and other languages. This tools is completely free
• Visual Studio Professional: more tools dev oriented for debugging, integration and team interconnection
• Visual Studio Enterprise: developer’s dream, everything is here
• Visual Studio Core: editing and debugging on any OS in a simplify environment
• Visual Studio for Mac: develop apps and games for iOS, Android, and web using .NET (Xamarin)

Visual Studio is really cloud oriented. There is a total integration with Azure, the Microsoft Cloud. You can explore all Azure resources directly from your Visual Studio.

Azure is the Microsoft Cloud. You can deploy every kind of applications built with any languages, not only .NET: it is a very friendly environment and easy to use, in the usual Microsoft style.

In Azure you can create different subscription (you can think a subscription as an environment, for example a subscription for test, another for stage and another for production). Under each subscription there are one or more resource group: a resource group is a collection of Azure services such as web applications, Azure functions, LogicApp, service bus and much more.

Proposed approach to managing deployments including the required Azure resources

Azure DevOps CDCI

Proposed approach for managing passwords and secrets

KeyVault

Benefits to Acme of the approaches above

...

Any key risks or assumptions

...