I have the same concerns as Ben, so it was nice to see I'm not alone with them.

being mainly a backend dev myself, it's hard to let the 12 factor principles go.

but I think in certain cases we have to. and I have seen signs already.

first I got into a project using Angular where the frontend was built every time it was "promoted" to production (ng build --prod). I thought this is weird but what frightened me the most is that this feature is built into one of the top frontend technologies currenctly used around the world, so these top engineers thought it was normal not to be 12 factor. what am I missing here?! but since this app was not a static site we could ignore them and load the settings at runtime from GET /config, problem solved (each /config is per env).

now I've got into another project where the output is a static site. you have code in git and content in a headless cms system. both can be versioned using branches. and here's where I'm totally lost: you can build the final artifact as a combination of code and content. this means theoretically a carthesian product: "test" code with "test" content (content+schema!), "test" code with "production" content, "production" code with "test" content and so on.

also these binaries are all different. and most of these combinations don't make sense, I understand that, but this is still very different from a backend service where you build a binary from a commit and promote it all the way to production.

and all we wanted was a static site :) I'm curious how other people see/solve/simplify this problem.