[philipbjorge]

My context has been startups with engineering teams of 15-60 engineers.

In general, I've found CI/CD templates, IAC templates and app templates to be an anti-pattern. It goes to the heart of scalable vs replicable.

> Put simply: something replicable can be copy-pasted (with variations as needed) to grow impact linearly in relation to effort and cost. Something scalable can create impact at a rate that increases faster than the rate at which your effort and costs increase.

In the contexts I've worked in, templates enabled us to rapidly grow and expand our business and technology in unmaintainable ways.

We scaled to 100 services, but our revenue and headcount didn't scale linearly to support the services over time.

---

In general, I lean towards solutions that facilitate distributing and updating templates over solutions that facilitate copying/pasting templates.

- Kubernetes this meant a common Helm service chart for the organization -- Now we could distribute and update kubernetes manifests to the org - CICD this meant building plugins that we distributed to teams - Application templates I've historically moved folks back into monoliths but the microservice chassis pattern looks like a solution here -- https://microservices.io/patterns/microservice-chassis.html

Your calculus might look different depending on your internal capabilities and resources. Good luck!

[Atotalnoob]

Perhaps I wasn’t clear in my post. Templates to me means distributing them in a usable fashion, and all templates should be able to be used via invoking some binary and providing inputs/flags.

Similar to helm.

Right now, we are using dotnet new templates, which is .net’a way of creating new apps, yeoman for npm, etc.

No copying and pasting. Copying and pasting isn’t DRY and is currently ramped at my org, since we didn’t have any shared templates

[ildjarn]

What’s the deal with templates? I make new projects infrequently. Templates save me little time. I spend far more time struggling to fix broken code, fitting existing code to new requirements, etc

[funcDropShadow]

Templates to me means distributing them in a usable fashion, and all templates should be able to be used via invoking some binary and providing inputs/flags.

I am wondering why nobody talks about using version control tools for templates. Git lacks the ability to replace variables and handle flags, but it allows to rebase a small micro service on top of the latest version of the template.

[Atotalnoob]

These are version controlled. We use semver and they are released using the languages package manager :)

[funcDropShadow]

And how do you update a project started with template x version 1.2.3 to template 1.3.4?

[8note]

How often do developers have to make the same changes to their dotnet new templates? How often will they have to make changes as a result of the central team making an update to the central template that breaks their setup?

When somebody needs to use an escape hatch, how painful are you gonna make it to keep that escape hatch running?

[Atotalnoob]

So essentially in dotnet, when you create a new project, you run

Dotnet new templateName

Dotnet runs that template and out comes dotnet code.

That is what we have built and we consume internal libraries we created in order to keep people updated with changes.

But at the end of the day, it’s just dotnet code, don’t like what or how we did something? Go ahead and change it. It’s just regular code.

It’s similar to running “helm create {name}” or npm run create-react-app, but developed internally.

https://github.com/dotnet/templating/wiki/Available-template...