azd init should also create infra, CICD: .github/workflows or .azdo/pipelines folders

[jongio]

Right now azd init creates .azure, .gitignore, and azure.yaml.

It should also create a /infra folder with main.bicep, resources.bicep, and main.parameters.json.

[ellismg]

What will we put in these files and why? Why wouldn't a user use --template in this case? I think we should be minimizing the number of files that are created with init especially in cases where you aren't using a template.

[jongio]

This will help when azdev-ifying a template. We expect the /infra folder to have the files mentioned above, we should have the placeholder files with the required name, location, parameters and env var replacements. Otherwise the azd-ify expereince will always include a step to copy those files to the infra folder.

[puicchan]

We should consider having a new command for azdev-ify a new or existing project, like azd create.

• I have tried azdev-ify a few templates and had to manually add the same applicationinsights.bicep file. We can provide an option to pull the applicationinsights.bicep from an azd template.
• Also, for azd pipeline config, I had to manually add .github/workflow; copy and paste the same azure-dev.yml file from an azd template.

[Gordonby]

passing a switch to azd init for a full scaffold might be a good idea then 😉

azd init --full-scaffold

[spboyer]

azd init new

[jongio]

Let's use this opportunity to discuss scenarios/workflows for azdevifying applications. @puicchan - Do we have a work item to track that? If not could you start one? We can close this issue in favor of an uber azdevify issue.

[weikanglim]

@jongio @puicchan @savannahostrowski

I'd like to separate this issue out from azdevifying (covered by App fingerprint #705). In that flow, we will generate azure.yaml with all projects scanned from existing code, and infra folder from an existing template.

However, I'd like to use this issue to fix the user journey of azd init from scratch. The idea is to guide the user along. Not having the user visit the documentation page unless they want to deep-dive is a win in my books.

Proposal

azd init shows "Starter Template" instead of "Empty Template" for the first selection in the prompt.

The "Starter Template" will have the following:

• Valid azure.yaml with comments helping the user along.
• Valid infrastructure files that sets up azd environment tagging + creates an empty resource group. In the future, we could call out to our core bicep registry as a quickstart.
• Starter GitHub or AzDo workflow template for CI/CD.

Asset files for "Starter Template" will be stored and shipped in our binary using go:embed, since we want the starter template to always stay in-sync with the azd binary.

[savannahostrowski]

+1 to what Wei is suggesting above. I really like this proposal. We need to get a bit better at guiding new users and having them fall into a pit of success.

[puicchan]

I am fine as long as you think about the scenario when customers have an app (with or without Bicep files) and still can use azd init to scaffold the basic azure.yaml, CICD workflow, etc. files they need. We need to make sure they are set up for success if 1. they do not want to use App Fingerprint 2. App Fingerprint is not able to give them what they need and they run azd init the second time to manually set things up.

[jongio]

I'd also include .devcontainer files

[rajeshkamal5050]

@savannahostrowski @ellismg Not in scope for GA. Moving this to Gallium.

[savannahostrowski]

I think this is polish. I'd like to talk about addressing this before GA.

[spboyer]

+1 @savannahostrowski , I'd also add that in addition to polish, this sets up a user for success when starting their own template, devifying their own, or working on a "build-up" process. Seems an easy win pre GA.

[weikanglim]

We're going to first add starter assets for bicep and terraform, the proposal has been finalized with @savannahostrowski 's blessing as follows:

Changes

azd init shows additionally "Starter - Bicep (azd-bicep-starter)" and "Starter - Terraform (azd-terraform-starter)".

The starters are just like other existing ToDo templates, available @ Azure-Samples/azd-bicep-starter and Azure-Samples/azd-terraform-starter respectively.

The starters have the following:

• Valid azure.yaml with comments helping the user along.
• Valid infrastructure files that sets up azd environment tagging + creates an empty resource group.
• Starter GitHub or AzDo workflow template for CI/CD.
• .devcontainer for a basic setup.

We will rename "Empty Template" -> "Minimal"

Testing

The templates will be validated via our normal bicep-lint processes, and in template-tests.sh a provision + down is performed to ensure the template can be provisioned. Deploy is skipped since no code is available.

[jongio]

@weikanglim - Please use azd-starter-{name} format so we can always have azd starter at the beginning of the name and add more tech/options down the road. cc / @savannahostrowski

[weikanglim]

@jongio Naming is hard. I can see us going either way on it, but I do find that azd-bicep-starter reads better than azd-starter-bicep. azd-{scenario}-starter is also a perfectly valid format IMO. I hope we're not over-optimizing for our slight internal benefits.

@savannahostrowski @ellismg

Some data from Microsoft repositories suggests that *-starter-kit seems to be popular.

https://github.com/orgs/microsoft/repositories?q=starter&type=all&language=&sort=
https://github.com/orgs/azure/repositories?q=starter&type=all&language=&sort=

[weikanglim]

Late thought here: Do you mean it's better for search engines to do azd-starter*? And organizationally, it may help group starters? I could see those benefits. Just want a second guidance before moving in that direction.

[savannahostrowski]

I'm not sure that having bicep/terraform ahead of starter in the repo name really optimizes for anything. I'd probably just go with what Jon outlined above for easier grouping etc.