[Release Planner] improve the route of a release plan for brownfield service
- Dominant language
- C#
- Stars
- 135
- Forks
- 260
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 143
Description
While most brownfield services are already experts of SDK onboarding, could we simply the steps in a release plan, let them create a SDK release request with minimum efforts? Some feedbacks from the brownfield services I served:
Azure Storage - the team has a dedicated team working on SDKs, while API specs are developed by different service teams of the same RP. This means when a developer comes to create a SDK release request, the API spec PRs (usually not only one PR) are already reviewed and merged. The storage SDK developer asked "if I could skip the steps of API readiness?"
Azure Network - multiple services working on the specs under network RP root folder, and Network has a huge SDK package. They are confused which service to choose when onboarding to request a release, because, as I mentioned, there are multiple services under Microsoft.Network. (LaDonna guidance is to pick one of them. Then the question is how to avoid duplicate requests ?) On the other hand, the team was pursuing to create a SDK release after API spec PR was merged as well. However, the release planner still forced them to go through each step of API readiness.
Contributor guide
Assessment
This issue has not been assessed yet.