11–20 of 66 posts
"Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything." From this, it sounds like Jenkins is automatically picking up new topic branches, running the tests, and reporting on the results. Any suggestions on how to set…
"Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything." From this, it sounds like Jenkins is automatically picking up new topic branches, running the tests, and reporting on the results. Any suggestions on how to set…
One simple (perhaps too simple) way to implement this would be to run a script which enumerates branches and exports the name of the most recently touched branch to an environment variable. Then, parameterize the build on that environment variable.
I'm curious how CI is done on branches. It's mentioned but not elaborated on in the article.
One question i've always had: How often do "regular" people commit? Should I be committing every time I hit save... or should I wait? (I don't work in a dev team, so I'm looking for the wisdom of developers who have to work in teams.)
Other than that, if you felt like you've taken a decently-sized chunk out of whatever problem or feature you're currently working on, commit.
One question i've always had: How often do "regular" people commit? Should I be committing every time I hit save... or should I wait? (I don't work in a dev team, so I'm looking for the wisdom of developers who have to work in teams.)
Make sure your commits are cohesive to the change you are making. I think that is a good rule of thumb.
"Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything." From this, it sounds like Jenkins is automatically picking up new topic branches, running the tests, and reporting on the results. Any suggestions on how to set…
Anyone know of ideas for doing code reviews for the whole pull request, commit, or a single line like GitHub? This is probably the most beneficial part for us.
One question i've always had: How often do "regular" people commit? Should I be committing every time I hit save... or should I wait? (I don't work in a dev team, so I'm looking for the wisdom of developers who have to work in teams.)
In the weeks before a new site is launched, we work to our own feature branches and merge into master when a feature is complete. In the run up to the site launch, when there's just CSS tweaks and the odd bug fix, people start working on directly master and deploying straight to staging servers.
When a site has been launched we normally keep working just on master, though occasionally creating feature branches for bigger changes.
This seems to work well for us as our DVCS needs change over time. I'd be interested to hear how other web agencies manage the different stages of developing clients' websites.