Azure
Hooks analysis and learning
Background and context
We now have over 100 templates and many more applications using azd to deploy to Azure. We can see that developers use the hooks feature to accomplish many things. In order to understand the patterns and to help developers accomplish their goals faster, with less work, and more consistency, we want to understand the common use cases and patterns in how developers use hooks.
Once we understand the demonstrated needs, we will use that data to make creating an azd template or azd-ifying an application more straightforward with less scripting. This might mean new core azd features, a shared library or package manager for common hooks, reusability guidelines, and refactoring our documentation.
Some common use cases and patterns we see today are:
- data initialization
- multiple data sources (DB, API, PDF, etc.)
- multi-platform (Linux, MacOS, Windows)
This is not a complete set. To find the classes of hooks we will do a combination of qualitative and quantitative customer research to come to a "top 3" list of the most common things we see template authors do.
Gather data
- [ ] Programmatic script
- [ ] Customer survey
- [ ] Retrospective observation narrative
Programmatic script
Things we want to learn from the quantitative analysis:
- [ ] % of all projects using 'hooks'
- [ ] average number of
hooksper template - [ ] reasons developers use 'hooks'
Customer survey
Things we want to learn from the customer input:
- [ ] more first-hand from our most frequent template authors
- [ ] opportunity for multi-select options and verbatim feedback
- [ ] Pamela, Jon, Shayne, and Brady have been identified as first group to send the survey (still discussing if it's valuable to expand this list externally)
Retrospective observation narrative
- [ ] document learnings from recent AI templates project
Next steps
After we've gathered more data, we will determine the top 3 things we see developers do when authoring a template or azd-ifying their application. We will then decide the best way to approach the solution.
We have a couple of use cases where we deploy Logic Apps and Functions with API Management, where the APIM operations need the Lapp/Function trigger URLs with their deploy-time generated keys to set up the backend. APIs are resources deployed by Bicep, so they would come first, except that on first provision the URLs they need don't exist yet, so we have had to run a separate deployment using az deployment group create to provision the API and retrieve the function key in that deployment
We have also used a hook to run Entity Framework migrations.
I'm using AZD to deploy code sample web applications and their corresponding databases using managed identities (read: passwordless). Hooks allow me to take the endpoints for the deployed services and apply them back to the local development environment using dotnet user-secrets init. The ideal state is for the dev to azd init, azd up, and then either see the running production application or start working in dev with the same data.
Moving on to the next phase of creating "Named Hooks" for the most common tasks that custom hooks are used for. Thank you for the feedback @seesharprun and @TWolversonReply for your input.
Follow along with the next steps in this work with https://github.com/Azure/azure-dev/issues/4290.