Session was about an high level view of the Gerrit Code Review workflow and his benefits in encouraging collaboration around the code and collective ownership of the Software Project. Moreover we have seen how Code Review and Continuous Integration can bring the “early integration” together with the scoring and promotion of changes into mainstream branches.
- Workflows, Branching & Merging (View on demand)
Learn the basic concepts of Git and Gerrit and see explore the power of merging and applying code from different branches thanks to recursive merge, rebase and cherry-pick.
- Peer Programming & Code Reviews (View on demand)
See how Gerrit Code Review can enforce full code collaboration and collective ownership, similarly to peer programming you can achieve faster and better code delivery. Learn how to integrate Jenkins CI into the development process and have automatic validation to feedback into your code review workflow.
- Hands-On Lab with Gerrit & Jenkins (February 12th) << Next Webinar
Step-by-step hands-on with Gerrit to learn how to move your first steps with Code Review: contribute your change, trigger your Jenkins CI validation and learn how to understand the feedbacks and amend your code for achieving a successful merged change into the main branch. Learn how to manage multiple reviews when the code evolves.
See below the full log of Question and Answers of the Gerrit Code Review webinar, brought to you by GerritForge LLP in order to give you the opportunity of getting more insight on Gerrit and trigger more discussion and feedback on Code Review.
Gerrit Code Revew – Q&A
Q: Please stop selling and instead show us the features.
A: The initial two webinars focus was more on the concepts introduced by Git and Gerrit, alongside with their support in commercial tools such as CollabNet TeamForge ALM product: this may have been perceived as “product selling” rather than functional and conceptual introduction to Code Review; that was not really our intention.
The third Webinar of the series (Hands-On Lab with Gerrit & Jenkins – February 12th) includes a step-by-step hands-on lab on how to use Gerrit from both Web-UI and command line for managing the Code Review workflow in a real-life environment, integrated with Jenkins CI Gerrit Trigger plug-in for code Validation. We will use Gerrit 2.1.8 embedded in CollabNet TeamForge 6.2 for our lab exercises, however they same exercises can be repeated with any other version of Gerrit.
Q: what were the three branches you mentioned? (1: _____ branch, 2: stabilization branch, 3: ______ branch)
A: You typically have at least three branches on your Git repositories: 1. main development branch (master), 2. stabilisation and release branch, 3. production and maintenance branch. The level of access control and code-review workflow you may want to apply to different branches is potentially different: Gerrit Code Review allows the definition of ACLs on a per-branch basis, allowing to easily manage a more fine-grained access to contributors on development branch whilst putting more strict control and validation on stabilisation and production branches.
Q: I tried to POC Gerrict but fell at the 1st hurdle – the login to webiste was insisting on an OpenID logon – we run behind a strict firewall so OpenID did not work – is there a way to allow a simple logon process at least for the QA
A: Gerrit Code Review set-up typically requires to have an existing user registry for authenticating users: I suggest to use a simple plain LDAP configuration rather than OpenID (i.e. you could download ApacheDS to set-up a sample registry) or download the CollabNet TeamForge 6.2 VMware appliance that includes Gerrit 2.1.8 integrated with CollabNet user registry.
For a more recent Gerrit 2.5.1 binary distribution, you could download the GerritForge 2.5.1 binary distribution that includes a step-by-step setup procedure that provides: 1. creation of an initial administrative account without the need of any external user registries or LDAP, 2. initial configuration of groups and roles, 3. sample repositories ready to be used as templates.
Q: Can Gerrit be used in Linux and Microsoft OSes ?
A: Gerrit is a Java EE based application; can be hosted in any OSes that supports Java JDK 1.6 or later. There is still a binary dependency on Git executable in the Gerrit wrapper start-up shell: this can be simply resolved by porting the gerrit.sh to the target Operating System you want Gerrit to be hosted.
GerritForge 2.5.1 for instance is available for all major UNIX platforms, Mac OSX and Microsoft Windows Servers and is integrated as automatic native system service.
Q: How Gerrit was different from sonar and hudson integrated to SVN ?
A: Sonar and Hudson are excellent tools for executing of a number of quality checks every time that a commit is created. However they do not include the ability to provide change-promotion based on voting plus collaboration tracking in terms of ideas and comments to the code. They remain however excellent tools that can be used as complement to the Code Review process, for providing additional automated score on change-sets uploaded to Gerrit.
Q: Is there any good web based code review tool like Gerrit on Subversion?
A: There are definitely other tools on the market, for instance CollabNet TeamForge includes ReviewBoard whilst Atlassian has its own Crucible commercial product: both can be used on top of other SCMs including Subversion. They are not comparable to Gerrit though, because the underlying SCM is not powerful as Git: when managing code-reviews you do need the ability to amend your code history and merge changes back to the target branch when review is completed. Subversion and other SCMs do not provide that flexibility, as a consequence the code-review on top of it cannot provide all the functionalities provided out-of-the-box by Gerrit.
Q: Can we integrate Bugzilla and / or QC with Team Forge
A: CollabNet provides integration to HP QC with his connector architecture; potentially its CollabNet Connector Framework would allow integration with other SCMs such as Bugzilla.
If you would like to just integrate change-sets to issues, Gerrit includes a generic Issue-Tracker Connector framework that allows to connect to potentially any external Issue-Tracker. Bugzilla has been recently supported by WikiMedia and HP QC is currently in the GerritForge 2.6 pipeline: those plugins allow Gerrit to talk directly to QC and Bugzilla for associating code commits and code reviews to existing issues and linking their respective workflows together.
Q: What are the major differences between Gerrit/Jenkins and existing enteprise application testing tools such as Junit/ANT or Oracle Application testing framework? Can they be integrated with Eclipse IDE for code reviewing and testing purposes?
A: Gerrit/Jenkins are not integrated out-of-the-box with Junit/ANT or Oracle Application Testing tools: main purpose of Gerrit is not to execute tests against the code but enforcing maximum visibility of changes in the Development Team and beyond.
Gerrit itself does not enforce the numbers and nature of checks against your code; however Gerrit can be potentially integrated with Junit/Ant and Oracle Application Testing tools to collect their feedback and track as score into a change-set review. From Gerrit 2.6 the code-review functions will be available even via RESTFul API: automation through Ant will be possible via scripting or custom tasks. Gerrit is already integrated with Eclipse IDE via Mylyn and its native Gerrit plugin: it allows to receive feedback in realtime on incoming code-reviews and display comments as annotations inside Eclipse standard code editor.
Q: Can we Integrate Maven and / or Ant with Team Forge
A: TeamForge provides a SOAP Interface and both Java and Python interface to access via external tools or scripting. This means that potentially both Maven and Ant can be used for accessing TeamForge artifacts.
Q: Can we block commits to the master branch and only use ref/for/master and force commits to gerrit code review ?
A: Yes, by using Gerrit fine-grained ACLs to refs/heads/master and allowing push for review to refs/for/refs/heads/master.
Q: Slide #28 (Gerrit workflow): What happens if master contains code conflicting the check-in of A2* (because this check-in was done prior to change A2*)? Can Gerrit auto-resolve this conflict?
A: No, as Gerrit does not know how to resolve automatically a conflict: Gerrit can try to merge the code anyway, depending on the Gerrit project settings, but if a conflict is detected, change-sets cannot merged back into the branch.
Q: That overview graph (CI + CR with traffic lights, branches) you showed was very helpful, to see what you are talking about. Which tools were you saying that covered? Gerrit and Git? TeamForge?
A: Workflow shows the usage of Git, Gerrit Code review and Jenkins CI together to validate a Change-Set and merging it to master branch. Master branch is always with a “green” street light (Build is healthy) whilst the “red” and “amber” lights are only on the refs/for/master (code-review branch) and do not impact the rest of project team development. TeamForge is the ALM to connect everything together (Git, Gerrit and Jenkins) in a unique environment.
Q: Is there integrations between other CI with TeamForge?
A: TeamForge provides integration with Cruise Control and Maven as well. Potentially other Continuous Integration tools can be integrated with TeamForge by using the SOAP or Java and Python API.
Q: Just wondering number of paritcipants on call, to relate to % in polls.
Q: How would you recommend a small distributed group (4 devs, 2 testers) to sort of “try out” this complex approach you are promoting here, while continuing to maintain our daily work via Subversion?
A: Git allows to pull and push back to Subversion, using the “git svn” commands. You can dedicate a branch (i.e. trunk-review) to experiment Gerrit code-review workflow, whilst keeping the rest of the development on the standard trunk branch. Once code-review is completed and merged to trunk-review, branch can be pushed back to Subversion and tracked as a normal regular commit. Bear in mind that Subversion does not have all the power of Git on merging code together, you may need extra manual work then to bring the changes back into the main trunk.
Q: How does Teamforge run Gerrit? Can Gerrit run as a Windows service?
A: TeamForge runs Gerrit into a separate JVM, activated and managed in the same way as any other TeamForge daemons. Gerrit itself can be activated either via gerrit.sh wrapper script or as standard Java WAR application into a standalone Servlet Container (i.e. Tomcat). In this second form it can be technically executed into a Windows service, such as Apache Tomcat running into a Java Service Wrapper.
Q: We’re using TeamCity as CI, can it be used and integrated with Gerrit ?
A: In theory they can be integrated, using Gerrit SSH or RESTFul (from Gerrit 2.6) scripting. See this example from Timothy Basanov BLOG. Unfortunately TeamCity is not OpenSource and thus has a more limited community of plugin developers providing integrations for Git and Gerrit. Jenkins CI has the world’s largest community of plugin developers for a Continuous Integration engine and already provides support for Gerrit Code Review workflow.
Q: Gerrit or Team Forge can help to migrate code from ClearCase to GIT?
A: Not really, they are not intended to drive migration from one SCM to another.
Thank you again for your attendance and don’t miss our next Webinar with CollabNet Inc, Tuesday, February 12, 10:00 AM – 11:00 AM PST.