Planning Poker 4 Azure
Live @ http://planningpoker.duracellko.net/
Planning Poker web application allows distributed teams to play planning poker using just their web browser and is optimized for mobile. The application does not require any registration at all. Scrum Master simply creates a team and all other members connect to the team. Observer role is supported too. The observer can watch the game, but cannot estimate. This is ideal role for a product owner.
How to play Planning Poker
This guide assumes that you already know what planning poker is about and how to play with real cards. If you need any information about planning poker see the wikipedia page. To play planning poker using this application is very simple. For distributed team a conference call is required as this is not provided by the application.
- At first Scrum Master creates new team by entering Team name and Scrum master name.
- Then all team members join the team by entering the same Team name and unique member name.
- Optionally product owner can join the team by entering the same Team name, unique member name and checking Observer checkbox.
- When all participants joined the team, the team can discuss first story.
- After discussion Scrum Master starts the estimation.
- Then all members pick estimates. Optionally Scrum Master can cancel estimation when any of the members requests that.
- After all members picked an estimate, the estimates are shown to all participants.
- If concensus is found then team can discuss another story and Scrum Master can start estimation again. Otherwise team discusses their estimates and then Scrum Master starts estimation again.
It is also possible to install the application using Docker image from duracellko/planningpoker repository.
docker pull duracellko/planningpoker
docker run -p 80:8080 duracellko/planningpoker
Application is implemented using ASP.NET Core 6.0. Front-end is Single-Page Application implemented using Blazor. This technology allows deployment to different environments:
- Locally on Windows or Linux
- In Docker container
- In Azure AppService
- or any environment supported by ASP.NET Core
The application does not have any dependencies to run in basic mode. However, there are configurable advanced features.
Blazor supports 2 hosting models: Client-side and Server-side. It is possible to simply switch between the models by configuring UseServerSide setting.
By default, when server application is restarted, all teams are lost. It is possible to specify folder to store teams data between application restarts. Team data are stored in JSON format.
Azure Service Bus
The application is state-full (it stores all teams data in memory). Therefore, it is not simple to deploy the application to a web-farm. Each server in web-farm would have different state of team. However, it is possible to setup Azure Service Bus to synchronize state between nodes in web-farm.
The application can be configured using default ASP.NET Core configuration sources:
- Environment variables
- Command-line arguments
The application has following configuration settings:
"UseServerSide": "Never" // string - Never | Always | Mobile
"RepositoryFolder": "", // string
"RepositoryTeamExpiration": 1200, // integer - time in seconds
"ClientInactivityTimeout": 900, // integer - time in seconds
"ClientInactivityCheckInterval": 60, // integer - time in seconds
"WaitForMessageTimeout": 60, // integer - time in seconds
// Azure Service Bus configuration
"ServiceBusConnectionString": "", // string
"ServiceBusTopic": "PlanningPoker", // string
"InitializationTimeout": 60, // integer - time in seconds
"InitializationMessageTimeout": 5, // integer - time in seconds
"SubscriptionMaintenanceInterval": 300, //integer - time in seconds
"SubscriptionInactivityTimeout": 300 // integer - time in seconds
UseServerSide (default: Never) - This setting has following options:
Always - Blazor runs in server-side and HTML is synchronized with browser using SignalR.
Never - Blazor runs in WebAssembly on client.
Mobile - Blazor runs on server for mobile devices and on client otherwise. Startup of Blazor can be slow on mobile devices, therefore this option fallbacks to server-side for faster start.
RepositoryFolder (default: empty) - Path to folder, where data are stored between application restarts. Path is relative to the application folder. When this setting is empty, no data are stored and all are lost on application restart.
RepositoryTeamExpiration (default: 1200) - Team is deleted after specified time with no user activity.
ClientInactivityTimeout (default: 900) - User is disconnected from the team after specified time with no connection from the user.
ClientInactivityCheckInterval (default: 60) - Time interval to run periodic job that disconnects innactive users.
WaitForMessageTimeout (default: 60) - Each client requests regularly for status updates. When there is no change in specified time, client receives response that there is no change and requests for update again. This way client notifies to keep connection is alive.
ServiceBusConnectionString (default: empty) - Connection string to Azure Service Bus used to synchronize data between servers in web-farm. For example: Endpoint=myEndpoint;SharedSecretIssuer=mySecret;SharedSecretValue=myPassword;
ServiceBusTopic (default: PlanningPoker) - Nodes uses the specified Service Bus topic for communication.
InitializationTimeout (default: 60) - Time after initialization phase is cancelled and server assumes that it is alone. This timeout should not be reached, because InitializationMessageTimeout is shorter.
InitializationMessageTimeout (default: 5) - Timeout to wait for message from another node during initialization phase. When the timeout is reached, server contacts another node or assumes that it is alone in web-farm.
SubscriptionMaintenanceInterval (default: 300) - Time interval to do periodic check, which nodes in web-farm are responding.
SubscriptionInactivityTimeout (default: 300) - Service Bus subcsriptions are deleted for nodes, which do not respond in the specified time.
Buid and test
- .NET SDK 6.0
- Java SE Development Kit version 8 or higher (for end-2-end tests only)
- Node.js and NPM (for end-2-end tests only)
To run build and tests simply execute PowerShell script BuildAndRun.ps1.
Optionally it is possible to include execution of end-2-end tests using Selenium.
Run in Visual Studio
PlanningPokerCore.sln solution can be normally open, built and debugged in Visual Studio 2019. Also unit tests can be executed.
For end-2-end tests (Duracellko.PlanningPoker.E2ETest) Selenium drivers need to be downloaded. Simply execute following commands:
PlanningPoker solution contains following projects:
PlanningPoker.Shared contains common settings for all projects. This includes build configuration, static code analysis, assembly version, etc.
PlanningPoker.Domain contains domain classes of the application. This includes domain logic and entities e.g. ScrumMaster, Estimation.
PlanningPoker implements host of domain objects, JSON web service and file-system repository.
PlanningPoker.Service implements DTOs shared between server and client.
PlanningPoker.Web is host application. It starts ASP.NET Core hosting, dependency injection and loads configuration.
PlanningPoker.Client is Blazor SPA client. It containes 2 pages, Blazor components and communication with the server.
PlanningPoker.Azure contains modified host of domain objects used on Windows Azure platform. Additionally it implements communication between cloud instances using Service Bus.
PlanningPoker.Domain.Test contains unit-tests of domain classes.
PlanningPoker.Test contains unit-tests of PlanningPoker project classes.
PlanningPoker.Client.Test contains unit-tests of client application.
PlanningPoker.Azure.Test contains unit-tests of classes in PlanningPoker.Azure project.
PlanningPoker.E2ETest contains end-2-end tests of full system. Tests are implemented using Selenium and tests mostly Chrome browser and partially Firefox.
This application including source code can be used under MIT License.