I'm building a Jenkins based CI for the first time. Here are the use cases I'm considering for it:
1. Ability to run Unit Tests, Integration Tests, & Acceptance Tests in Local Dev environment (without Jenkins). 2. Ability to run Unit Tests, Integration Tests, & Acceptance Tests in Remote Dev, Staging, & Production environments. 3. When code is reviewed & committed to Master branch then Unit Tests, Integration Tests, & Acceptance Tests are run in Remote Dev, Staging, & Production environments. #1 is a certainty, essentially a script to rebuild the app and run the tests on it. While this could be done in a few steps in the IDE, I think this script would be handy. Where I'm not quite sure about is the workflow that happens next. My first thought is that the developer will commit all of the changes in his branch, push these changes to the remote branch, and then issue a pull request. When the code is reviewed, approved, and the branch is merged with the Master branch then this will automatically call Jenkins as per #3. But what about #2? Is it common to give a developer the ability to run all of the tests first in these 3 environments (or maybe just Remote Dev?) before committing such changes? I would appreciate feedback from all CI experts out there! Robert -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8f30933c-a607-4c9c-a6cf-0ba425ffd1b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
