Change Details

==== 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 deploy services, so that I can deploy 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 [x] 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 ==== Links [] https://wikitech.wikimedia.org/wiki/Deployments [] ServiceOps/API Platform Meeting Notes: https://docs.google.com/document/d/10njQc1J8LwhtR3vTV3VSEnrOJ71vN4fgLPZ_ERJgqzw/edit#

==== 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, release engineering, legal, security, 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 have clear documentation about how to deploy services, so that I can plan ahead and deploy 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 [x] Review existing documentation [] Analyze possible deployment paths [] Bullet list of what the related infrastructure capabilities are [] Define known tasks including definition of done for each [] Define drivers for each task [] List of potential blockers in the process [] List of what this project blocks (if anything) and why. [] Organized list of Documents and links to existing artifacts, tickets, etc. [] 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 in a [[ https://office.wikimedia.org/wiki/Product/DACI | DACI ]] [] Add the process to the [[ https://miro.com/app/board/uXjVPGpQhlg=/ | workflows swimlane diagram ]] [] 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 [] The process is added to the [[ https://miro.com/app/board/uXjVPGpQhlg=/ | workflows swimlane diagram ]] ==== Links [] https://wikitech.wikimedia.org/wiki/Deployments [] ServiceOps/API Platform Meeting Notes: https://docs.google.com/document/d/10njQc1J8LwhtR3vTV3VSEnrOJ71vN4fgLPZ_ERJgqzw/edit#

==== 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, release engineering, legal, security, 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 ablehave clear documentation about how to deploy services, so that I can plan ahead and deploy 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 [x] 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 remainingDefine drivers for each 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 hubpotential blockers in the process [] List of what this project blocks (if anything) and why. [] Organized list of Documents and links to existing artifacts, tickets, etc. [] 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 in a [[ https://office.wikimedia.org/wiki/Product/DACI | DACI ]] [] Add the process to the [[ https://miro.com/app/board/uXjVPGpQhlg=/ | workflows swimlane diagram ]] [] 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 [] The process is added to the [[ https://miro.com/app/board/uXjVPGpQhlg=/ | workflows swimlane diagram ]] ==== Links [] https://wikitech.wikimedia.org/wiki/Deployments [] ServiceOps/API Platform Meeting Notes: https://docs.google.com/document/d/10njQc1J8LwhtR3vTV3VSEnrOJ71vN4fgLPZ_ERJgqzw/edit#