This message was deleted.

We're using the brain-dead approach. We have template string like

##REPLACEME##

in the locations where things need to replace, and a Makefile at the root of the repo that runs a script that looks like the above (in the case of this script, it just insert the name of the repo, it doesn't do string replacement, but same concept). It then commits, tags, pushes, and deletes itself.

Fair enough! We’re currently using https://github.com/RoadieHQ/roadie-backstage-plugins/blob/main/plugins/scaffolder-actions/scaffolder-backend-module-utils/README.md But it’s pretty much the exact brain-dead approach but the increasing complexity of the replaces is making us evaluate other tools in the wild 🙂

It may be one of those issues where the solution is to simply have more templates. Do you want to add the complexity of having a scaffolding system that can parse and understand a programming language, vs just adding an extra template repo? If you go with a re-factor rather than re-place approach, you'll need your refactoring solution to support the languages you use, you might need it to be installed wherever you run it, any engineers that work on the system will have a larger cliff to understanding it before they can change it, etc. Sed is pretty universal. But YMMV, I think it'll be very case-by-case.

We’re approaching this from a perspective of updating the infrastructure & deployment pipelines rather than the code primarily and since we’re not a k8s shop and are pretty much married to the cloud provider having an abstraction layer to provision the infra or a gitops agent based deployment pipeline isn’t nearly as feasible as in a k8s based platform. And whilst we could create newer versions of the scaffolder templates. Updating existing repos with changes in the CICD pipelines or updating IaC for devs is where we’re trying to leverage other tools

See this discussion: https://platformengin-b0m7058.slack.com/archives/C037XDKEDNW/p1684417238449559

This is very interesting! One question: how are you managing the expectations and level of implication with the App Teams? I see Platform Teams in big orgs not concerned about what runs inside the "boxes"

We are kicking the tires on this currently. Its coming down to a couple of choices… Do we build a workflow that just sees the “boxes” run to completion or do we not provide any abstraction at all and instead retain a lot of the control ourselves. One of the downsides I guess of our existing pipeline is that as we’re deploying serverless lambdas - we’re using github actions to assume roles in our AWS accounts to deploy new versions and create requested infrastructure using cloud formation - given that the runner’s role gives it enough permissions to do a lot of things - a concern raised is can people misuse the privileges to do things in the “boxes” that they are not supposed to which is where we’re toying with the idea of locking down the actions yamls with CODEOWNERS and using something like open rewrite to maintain all the repositories ourselves

That's an interesting idea @Shashank Murthy. I guess it can be hard to introduce those changes, specially to get the buy-in from the Upper Management. Any special strategy that you used there?

@Rodolfo Campos It requires quite some expectation-setting, so it's important that everyone are onboard, informed and are allowed to give their meaning about this. As usual culture is a hard thing to change. And it has to be backed up by Upper Management. Developers that see the value of DevOps are okay with this, while some devs that don't like ops at all, don't like it. It doesn't directly answer your question, but see our article for more details (google-translated from Norwegian).

Thanks for sharing the article @Yngvar Kristiansen! Nice read, specially the section about "Paved path vs self-built black-box". Definitely buy-in from the broader team is key. I wonder if there are any "experts" out there saying that you should care about what runs inside of the "boxes". That could definitely help us. Something I've been pitching recently is: if your apps running in the "boxes" are exposed to Critical or High CVEs, then your whole platform could be compromised. App patching should be 101 or 202 at least. Any experience on this?

@Rodolfo Campos We're currently in the early (1 year) phase, so we don't have too much experience. We do however limit blast radius by using separate accounts, as per AWS recommendations. This avoid the "whole platform" getting compromised.

We’re also following a multi account strategy for our serverless setup (one account per microservice boundary / Bounded context (Following domain design principles) and in the very early - pre prod adoption phase at the moment. I find that the ecosystem maturity level for serveless adds to complexity whilst setting up all peripherals needed to build a developer platform since we’re mostly having to build everything from scratch ( DevSecOps + delivery pipelines, Code repo generation, policy as code and platform maintenance and upkeep tools ) since the ecosystem is not as widely adopted as, say a K8s shop, where most of a platform team’s work is integrating ootb solutions and building only things that do not exist or need extensions using operators.