==== Background/Goal
As AQS 2.0 development nears completion, we need to learn how we will deploy it, and future services. We will need to learn from and collaborate with SystemOps and others as we design this process. Our goal is that the deployment process is scalable.
==== User stories
[] As an API Platform engineer, I want to be able to develop, promote, test and deploy my changes,
so that I can iteratively promote my changes with confidence
==== Considerations
- What capabilities are critical vs nice-to-have?
- What capabilities have the biggest impact?
- What capabilities have the most dependencies?
- How can we scope this work in a way that delivers incremental benefits?
- What value does this deployment process provide?
- What can we learn in this process that we can apply to future API Guidelines?
==== Requirements
[] A brief description of what the use case is
[] Review existing documentation
[] Analyze possible deployment paths
[] Bullet list of what the related infrastructure capabilities are
[] Define remaining known tasks including definition of done for each
[] Estimate remaining tasks
[] List of any potential blockers
[] List of what this blocks (if anything) and why. Include examples.
[] Documents and links to existing artifacts, tickets, etc. clearly organized in knowledge hub
[] Open questions/additional areas to explore
**Upon completion of the above:**
[] Tech Lead & Engineering Manager review together
[] Bullet list of potential/expected development/engineering impacts (both positive and negative)
[] Bullet list of potential/expected design impacts (both positive and negative)
[] Describe WHAT phases or chunks of work could be done and by WHO
[] List any dependencies we have on any tools, teams, etc.
[] Meeting set to review scope with Product Manager
[] Once scope completed and agreed to, next steps defined (ex: create Epic w/ subtasks)
====Acceptance criteria
[] Process defined is scalable, when possible
[] It is clear how the target capability impacts WMF staff and wider technical community
[] Impact can be delivered incrementally, without having to wait months or to the end of a project to see impact
[] Non-technical audiences can understand why this work matters and how it impacts the community