We fought the copy+paste drift for a while. Most jobs were very similar, but just different enough that debugging things when something went wrong was often both time consuming and frustrating.
Ultimately, we took an approach similar to Travis CI, or Gitlab CI [1], only using shell scripts since that plugs into Jenkins easily enough. Every project has a CI script and a release script in a common location relative to the project root that takes care of everything needed to take a fresh clone of a repository, run the tests, and deploy the project (depending on a few environment variables) if the tests pass.
We have 1-click operation to set up a new job in Jenkins, and it handles all the configuration based on an XML template. Everyone understands that they're not supposed to make manual tweaks to the jobs once they're set up, and a year later, things are working pretty smooth.
This way is the only way we've found to do it, even on a smaller scale. Once you get above 20-25 jobs, or create a self service way for teams to create projects+github+jira+cloudformation+jenkins etc, you have to aggressively standardize. Often this means standardizing on the lowest common denominator (shell script).
> Even if you've got the answer, sometimes it makes sense to let your team make the decision. There are often many right answers. Remember, your job isn't to choose a right answer, it's to ensure that the team doesn't choose a wrong answer.
Couldn't agree more. Allowing the team to own decisions as a group goes a long way toward boosting morale and giving each member a greater sense of pride and ownership. Sometimes people need subtle guidance away from poor choices, but often time, allowing people to explore options on their own-even briefly, they'll often make the right choice in the end.
I will echo this. SPAs can be great when done well, but my experience with them as a user suggests they're easy to do poorly.