ayan.poddar/eShopOnContainers
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Updated 01. Roadmap and Milestones for future releases (markdown)

Cesar De la Torre 2017-04-19 15:56:34 -07:00
parent ffd9d68c7a
commit 6225584ed0
1 changed files with 16 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
01.-Roadmap-and-Milestones-for-future-releases.md

@ -1,4 +1,4 @@
## Version 0.1 (ALPHA, current version - Early March 2017)
## Version 0.2 (BETA, current version - April 2017)
- Available at the MASTER branch.
- Docker containers with .NET Core and Linux images support/tested. Windows Containers are work-in-progress.
@ -7,31 +7,30 @@
- CLI build process using a Docker ASPNETCore build-image (microsoft/aspnetcore-build) with all the needed SDKs so the compilation takes place in the same container recommended to be used in your CI pipeline (Continuous Integration). No need to have all dependencies in the dev machine when using this method. [Using this CI docker-compose file](https://github.com/dotnet/eShopOnContainers/blob/master/docker-compose.ci.build.yml).
- Initial basic foundational microservice oriented architecture, easy to get started, described in this <a href='docs/architecting-and-developing-containerized-and-microservice-based-net-applications-ebook-early-draft.pdf'>**Guide/eBook** (Early DRAFT, still work in progress)</a>.
## Version 0.2 Roadmap (BETA, by mid-April 2017 timeframe)
- Support for Windows Containers running on Windows NanoServer using different Docker base images instead of the Linux based images
- Implement support for Windows Containers running on Windows NanoServer using different Docker base images instead of the Linux based images (.NET Core code should be the same as it is cross-platform) - Fork or the same repo?
- Build/compile process within an Integration Container (with a provided Docker Image with all SDK dependencies) instead of in local PC. This would greatly simplify the CLI developer's installation requirements in a local machine. That integration container should also be used from a CI pipeline.
- INTEGRATION EVENTS with Event-Bus implementations: Implement Event-Driven communication between microservices/containers based on Event-Bus interfaces and two implementation:
- INTEGRATION EVENTS with Event Bus implementations: Implement Event-Driven communication between microservices/containers based on Event Bus interfaces and two implementations:
1. (PRIORITY) Standalone Pub/Subs messaging implementation based on an out-of-proc RabbitMQ Container
2. (Future version) Azure-attached implementation based on Azure Service Bus using Topics for Pub/Subs
Two integration event scenarios to implement in the app:
1. Simple (higher priority): Change Product info (name, image URL, etc.) in the Catalog and update that in the existing Orders and Baskets (all, except the price)
2. Complex: Events propagating Order's states changes related to the Order-Process SAGA (InProcess, Paid, Handling, Shipped, Canceled if timeout because it was not paid, etc.) - Scenario to be discussed/defined
2. (Future version) Complex: Events propagating Order's states changes related to the Order-Process SAGA (InProcess, Paid, Handling, Shipped, Canceled if timeout because it was not paid, etc.)
- Implement security best practices about app's secrets (conn strings, env vars, etc.)
- Monolithic ASP.NET MVC app (just web app, no containers) with public area of the eShop (Home page with catalog-view functionality, basically). As segregated project available at: https://github.com/dotnet/eShopOnWeb
- Legacy ASP.NET WebForms client running on a Windows Container (Catalog Manager/Simple CRUD maintenance). Consuming the same Catalog microservice. This is an example of a "lift and shift" scenario.
## Version 0.3 Roadmap (BETA, by May 2017 timeframe)
- INTEGRATION EVENTS / Advanced: Prrof of concept of a Order-Process SAGA (InProcess, Paid, Handling, Shipped, Canceled if timeout because it was not paid, etc.) as a long running process.
- Implement security best practices about app's secrets (conn-strings, env vars, etc.)
(However, this subject depends on the chosen orchestrator...)
See when using Swarm: https://blog.docker.com/2017/02/docker-secrets-management/
- Monolithic ASP.NET MVC app with public area of the eShop (Home page with catalog-view functionality, basically). As out of band, separate project (same GitHub repo but separate folder and separate solution)
- WebForms client (Catalog Manager/Simple CRUD maintenance): In the Windows Containers fork, implement and add a client ASP.NET WebForms application (running as a Windows Container) consuming the same microservices, as an example of "lift and shift" scenario.
SCENARIO: A simple CRUD edit WebForms app for the Catalog, consuming the Catalog microservice to add/update/delete products. As simple as possible..
- Exception Handling - As an ASP.NET middleware?
Middleware from ASP.NET Core with custom implementation which records specific exceptions depending if it is in production.
Business-Exceptions + Generic-Exception-Handler (ExceptionHandlerHandler)
- Exception Handling - ASP.NET middleware extension: Business-Exceptions + Generic-Exception-Handler (ExceptionHandlerHandler)
- Validations with MediatR Decorator - FluentValidation
https://github.com/JeremySkinner/FluentValidation