that’s a good call actually. I got pretty hung up on domain objects being mostly data classes, but one approach is to have them perform business logic themselves.

(often abbreviated BS)

Thanks for that, I think Engines is winning in my mind so far!

I can’t believe they didn’t with go with BatShIt. it’s right there! they were SO close!

I just started using this at $jorb. Check out their “ui-mode” is all I’m going to say about that.

The sentiment of the first half of your comment is the cause of the problem you describe in the second half. Why /should/ the CI tool have any “steps” built in? Use a task runner, or script in your repo for any task you expect CI to do. Configure CI to run the same command you would run locally.

I personally recommend the ender 2 pro to all my friends who just want a taste of getting into it. You can get em pretty cheap online, or at microcenters. They work well pretty much out of the box, but simple enough to get you to learn tuning them. And they come with a magnet removable build plate.

All the better to read you with, my dear.

No wait, that’s backwards. Thanks for the feedback, I’ll play with the fonts next time I make a post.

My point is, having PRs desn’t result in perfect code either. They might help sometimes, maybe 10% of the time if I’m being generous, but the rest of the time they are a hindrance. The problems people tend to try and solve with them, validation and indoctrination are better solved with a good CD pipeline, and pairing sessions.

If your team consists of people you don’t trust, that’s the problem to fix first.

The solution to that is pairing - spending a few hours collaborating with, and teaching this person will get them up to speed much faster than asynchronously nitpicking their code.

Mandatory pull requests + approvals within a team are a waste of everyone’s time.

I agree. What I’m proposing is, if you go with that option, that you use a branch as a “single instance label”, pointing at commits within your main branch. Don’t use them as actual branches for additional environment-specific commits.

I would recommend you avoid relying on features of GitHub, and only use features of git. You never know when you might decide to switch repo hosting providers!

With that said, you’ve got a number of options: you can use tags or branches as “labels” to choose what’s applied to what environment, or depending on the flavor of IaC you’re using, have an entry point for each environment in your code which includes and parameterizes a common “environment” module.