search

Azure / template-specs

MIT License
31 stars 4 forks source link

Will template specs integrate with bicep #36

Closed jannickoeben closed 3 years ago

jannickoeben commented 4 years ago

How will the new dsl relate to template specs?

Will template specs be repositories for the intermediate language, or will they be able to store bicep files too?

Is the flow for single use: Write Bicep template > build to arm template > deploy to Azure

Is the flow for multiple use: Write Bicep template > build to arm template > deploy to Azure template spec Deploy template spec

Or will we be able to do: Write Bicep template > deploy to Azure template spec Deploy template spec

slavizh commented 4 years ago

I vote for bicep files be stored directly in templateSpecs just like ARM templates. Does not makes sense to build bicep files into ARM templates and store them as such.

alex-frankel commented 4 years ago

For the near future, the template specs will only store ARM Template JSON. That being said, we will update the template-spec CLI commands to accept a bicep file and compile it for you before creating the template spec. So to create a template spec you will be able to do:

az ts create -f ./main.bicep ...

At some point, it would be nice to store the bicep file directly, but no ETA for if/when that will happen. I think it's best to think of the ARM Template JSON as a binary/build artifact. All the downstream dependencies depend on that artifact (like a dll or an exe), so it's expected to need to generate the "binary" in order to use the tooling that supports it.

rikhepworth commented 4 years ago

With apologies to @slavizh I agree with @alex-frankel I feel strongly that when using Bicep, the ARM templates are a compiled artefact and as such would be stored in template specs (and uploaded as part of our pipeline) rather than storing the original bicep code. That latter approach feels wrong - it violates the principal of binary promotion between environments that I believe template specs is supporting.

J0F3 commented 4 years ago

I agree with @alex-frankel and @rikhepworth too. I think too that the JSON is like a compiled artifact which should then promoted / published instead of the source code (bicep code). This approach gives also more parity of IaC/ARM and full programming languages where also only the compiled version is published and promoted between environments (thinking of things like NuGet, NPM, Maven Packages). This parity makes it then also a lot easier to live software engineering practices also with IaC/Infrastructure which, in my opinion, should be the goal with IaC.

henrybeen commented 4 years ago

I would agree. If we were to store Bicep code in template specs, would I be able to use that directly then? And if so, which version of the bicep transpiler will be used (though I don't know if that would matter). Also might this not inspire scenarios around referencing bicep from arm templates and/or the other way round?

Besides the engineering difficulties for the team, I think the explanation to the user will become much harder.

EldertGrootenboer commented 4 years ago

I like the idea of having the template specs as a repository of “compiled” objects, aka ARM templates, better as well. Build your templates the way you like, either through bicep, farmer or directly, and store the template itself into template specs, where you can then deploy it from and reference it from. Decouples declaration from implementation.