3 ms·
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 bot
by escapee 11y ago
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.
[1]: http://doc.gitlab.com/ce/ci/quick_start/README.html http://doc.gitlab.com/ce/ci/quick_start/README.html
- killface 11y agoThis 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). thanks for sharing.