On Sat, Apr 9, 2011 at 7:43 PM, Matthew Barr <[email protected]> wrote:

> So:  What do people do for git:  web front end, code review tools, anything 
> else I'm missing?

We use trac and gitweb to support a manual peer-review system for
configuration management.  We have small sysadmin teams (3-5 people)
of generalists who work closely together already, so a formalized
code-review tool would be overkill.  We also just migrated existing
configs and code from subversion to git, so a lot of our workflow is
still very influenced by that (eg: we use branching sparingly because
the integration for git branches into some workflows just isn't there
yet -- that said, I find "git stash" worth the price of admission).

For commits, a hook in your local repo enforces a ticket number in the
commitmsg which will then link the commit to the specified trac ticket
via a custom plugin that adds commits in a list to the bottom of the
ticket 
(http://sourceforge.net/projects/sourceforge/files/Trac%20ShowCommitsOnTicket%20plugin/)

Once your commits are happy, you can paste the ticket link into the
group chatroom so that a peer (or peers) may review and discuss the
changes.  Obviously not everything needs a review (updating the
copyright date in a footer file, for example) so gitweb is handy for
visually reviewing recent changes to the repository without the Trac
overhead of having to sift though active tickets.  Once
approved/reviewed, changes are applied from the master branch.  Some
teams have puppet automatically pull master, other teams opt to
manually promote changes via their push tools.

This review method has a side benefit of introducing the
group-at-large to changes and keeping a minimal amount of
cross-training present among the team members.  Once a sysadmin team
gets to be about 8ish people, or if you have admins who have very
narrowly focused roles, this method starts to break down due to scale
and focus issues (ask 8 sysadmins to review a change and you'll get 11
answers and two jokes).

One of the things I'm working on now is better hook scripts so we can
check things at pre-commit time so that we can maintain a high degree
of accuracy even as we attempt to increase velocity (do things lint
correctly, is everything updated that needs to be, did you increment
the serial on that zonefile, etc...).  This is a low priority project
at the moment for me and I would love to hear any suggestions folks
have for git-hook-tricks in this regard.

Thanks,

-n
-- 
-------------------------------------------
nathan hruby <[email protected]>
metaphysically wrinkle-free
-------------------------------------------
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to