Abstract SDLC process
The raw engineering process for new API server projects is something like:
- Project code from central registry
- Define high level solution or solution on a page document (draft work in progress)
- Define subject domain (for use Domain Drive Design principles). Either create new domain name or use existing deomain name. This is centrally registered.
- Register exposed APIs in CMDB. OpenAPI and AsyncAPI can be serviced by same server. If following microservices principles, then discourage having multiple OpenAPIs.
- Determine infrastructure platform and register with infra
- Create Git repo based on naming standards
- Select framework
- Create shell OpenAPI with base level routes such as health and search (if applicable)
- Define OpenAPI (if applicable)
- Create shell AsyncAPI with base level routes such as health and search (if applicable)
- Define AsyncAPI (if applicable)
- Architecture and peer review of design
- Data lineage
- Server management SLAs
- Governance on privacy and availability, resilience and cyber rating
- Cyber security review of design, data flows and infrastructure
- Catalogue OpenAPI/AsyncAPI
- Lint the OpenAPI/AsyncAPI
- Create server code - could initially be generated based on OpenAPI/AsyncAPI followed by manual tweaks
- Create unit tests
- Create build script
- Create unit test script
- Create build pipeline
- Authentication and authorisation registration of API server
- Register consumption of upstream API, in operations management gide, for security and access rights
- Register API server with routes in external and internal gateways
- Register health monitoring (e.g. health route)
- Include and register for standards such as monitor, logging, security, fraud, feature switch, alerts
- Define external and internal gateway configurations for API
- Create roll out script
- Create roll back script
- Deploy to staging and test roll out and roll back processes
- Register solution for release / deployment either immediately or next change window