Skip to main content

Employee Deployment and Startup

Summary

Employee Service builds as a .NET release artifact and starts as an ASP.NET Core process; migrations occur before endpoint mapping completes.

Audience

  • DevOps engineers, developers, QA engineers, and support engineers

Deployment/startup flow

Dependency expectations

A usable deployment needs valid database and authentication configuration. Gateway, UI, messaging, and observability availability affect broader operation but are not proven by the basic health response.

Post-deployment checks

Confirm process health, migration completion through approved evidence, authenticated tenant isolation, compatibility/direct smoke results, correlation-bearing logs, and route-source ownership. Do not infer message delivery merely from service health.

Rollback boundary

The source defines no Employee-specific deployment rollback automation. Runtime artifact and gateway routing rollback are owned outside Employee Service; database changes and data written after cutover require reconciliation review. Exact platform procedures Require confirmation.

Source References

  • microservices/src/employee-service/Program.cs
  • microservices/src/employee-service/Dockerfile
  • microservices/src/gateway-api/Program.cs
  • microservices/src/employee-service/Infrastructure/Migrations/
  • microservices/src/employee-service/Properties/launchSettings.json

See Also

Keywords

  • service startup
  • deployment validation
  • migration startup

Revision Information

  • Status: Draft
  • Last reviewed: 2026-07-15
  • Review cycle: Quarterly