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
- 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
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,
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
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.
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
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
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
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
Proposed development toolset
- 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.
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
...
