search

Azure / azure-sdk-tools

Tools repository leveraged by the Azure SDK team.
MIT License
109 stars 166 forks source link

[Release Planner] improve the route of a release plan for brownfield service #8392

Open josefree opened 3 weeks ago

josefree commented 3 weeks ago

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.

ladonnaq commented 3 weeks ago

Related to https://github.com/Azure/azure-sdk-tools/issues/5566.

maririos commented 3 weeks ago

Related to https://github.com/Azure/azure-sdk-tools/issues/5566.

We will prob not change the flow too much though, so the requirements from Josephine will still be valid.

I understand that the release plan might not work for everyone. Right now our priority as a team is to gather data from the whole process and not just about releasing an SDK. Having both steps help us with that. What I see is that teams don't know about the Release Planner until they are working with the SDKs, and that is something that needs to be fixed. We want them to know about our team since the very beginning.

We could for sure improve this experience in the future, but at least for Dt we won't make the neccesary changes

ladonnaq commented 3 weeks ago

Related to #5566.

We will prob not change the flow too much though, so the requirements from Josephine will still be valid.

I understand that the release plan might not work for everyone. Right now our priority as a team is to gather data from the whole process and not just about releasing an SDK. Having both steps help us with that. What I see is that teams don't know about the Release Planner until they are working with the SDKs, and that is something that needs to be fixed. We want them to know about our team since the very beginning.

We could for sure improve this experience in the future, but at least for Dt we won't make the neccesary changes

We can simplify the API readiness flow for brownfield services but first we have to be able to identify all release scenarios, then we can customize the release plans. We are doing the work this semester to identify the release scenarios, so it will not be until next semester that we will be able to customize the release plans. I would not support eliminating the API readiness milestone for brownfield services. The Network and Security RPs have dedicated teams that handle the SDK release process for all of their products but every other Brownfield services uses the default process. We must ensure that the API Spec is merged. In the future, we may be able to identify the Network and Security scenarios by the RP, and then modify the release plan accordingly but teams will still need to create and use release plans. They drive the SDK team's release process.