About Git and Gerrit Code Review for the Enterprise

Official blog for GerritForge

[Poll] Gerrit User Summit 2017

user-group-crowd.jpg

At the last  User Summit in Mountain View, it has been announced that the Gerrit User Summit 2017 could be hosted in Europe/London rather than the traditional US West Coast location.
The primary rationale behind the proposal is to engage with a wider and more diverse community, who can bring new requirements and needs from of the European Gerrit Community. It would be an opportunity to see more faces and get new ideas.

While the adoption of Gerrit Code Review has been historically high in the USA, the European companies have started using it as the standard tool for their development lifecycle. More and more people from Europe began to participate actively in the mailing list and contributing new ideas and code.

Here is a poll to have your say and express your intention to participate:
https://goo.gl/M7X6rp

The poll will stay open for the next two weeks and then we’ll publish the results.

Thank you in advance for taking the time to respond to the poll and hoping to see you soon at the next Gerrit User Summit 2017.

Luca Milanesio – GerritForge.

GerritHub.io powered by Polymer

polymer-logo

You can now use the Gerrit Code Review interface on GerritHub.io using the new Polymer-based UX. The code-name of the project is PolyGerrit.

Enabling Polymer is easy, just add “?polygerrit=1” to the regular GerritHub.io URL. or alternatively you can click on the  “PolyGerrit” link at the bottom of the GerritHub.io footer.

https://gerrithub.io/?polygerrit=1

Alternatively you can click on the  “PolyGerrit” link at the bottom of the GerritHub.io footer.

polygerrit-footer

What is Polymer and why it matters?

Polymer is a new type of library for the web, built on top of Web Components, and designed to leverage the evolving web platform on modern browsers. Differently from the traditional Gerrit GWT UX, Polymer is developed using  HTML and JavaScript and is supported and cached natively from your web browser.

Why is Gerrit moving away from GWT? Well, there are many reasons for steering direction:

  • Speed.
    With Web Components, the core building blocks of the UX are transferred once and then cached by the browser, giving a much faster and fluid user experience.
  • Multi-sized screen support.
    Web Components are “instructed” to be rendered differently on different devices, giving the best user experience and accessibility of the device’s form factor and native interactions.
  • Branding.
    By using native HTML and CSS rendering, it becomes much easier to control and customize the look and feel of Gerrit.
  • Stability.
    Web Components development allow focusing on basic building blocks that are straightforward and testable. It becomes much easier to develop much more stable and robust components.
  • Skills-set.
    Typically, web developers find themselves more comfortable in using a front-end language and have much more control of what gets generated, understood and rendered by the web browser.

GerritHub.io on mobile

One interesting feature of PolyGerrit is the mobile view of Gerrit UX.

polygerrit-on-mobile

Gerrit’s GWT interface has always been quite a challenge on small-screen devices, mainly because of the inability of being sensitive to the reorganization fo the page real estate based on the device’s form factor.

Additionally, the buttons did not have enough real estate needed for “big thumbs”.

The ability to use Polymer has opened up a wide range of possibilities of interactions and, for the first time, a real fully featured review experience “on the road”.

Big thumbs up for the new Gerrit Mobile UX !

What and when?

What is currently implemented in the new Gerrit Polymer-UX? Not much in terms of screens, but a lot of the core functionality of the Code Review: the changes list and the review panels. What is missing? All the other Gerrit screens more dedicated to the management of the platform and the account, the projects and groups listing, and all the support for the UX plugins.

The PolyGerrit project announced at the Gerrit User Summit 2016 last year that they are making good progress and expect to have the first “production-ready” release by Feb/Mar 2017. In the meantime, all the code is stable and the current screens are good enough to be used on a daily basis.

Do I still need the GWT UX?

Yes, at least for the functionality that isn’t available yet in PolyGerrit. To switch back to GWT, simply add “?polygerrit=0” to the target URL.

https://gerrithub.io/?polygerrit=0

Credits

Many thanks to the Google’s PolyGerrit Team, lead by Andrew Bonventre, which started the Polymer support for Gerrit UX. A special thank to David Ostrovsky, who implemented the Gerrit switcher support to enable to use both GWT-UI and PolyGerrit-UI at the same time.

Gerrit User Summit 2016 Report

gerritusersummit-2016-google

The 9th edition of the Gerrit User Summit has ended today: a lot of new features and ideas have been presented and experimented in those four days.
Here is a summary of what happened and a description of the main innovations and presentations at the Summit and Hackathon at GooglePlex in Mountain View – CA.

12th-13th of November – The Summit

Gerrit v2.13

David Pursehouse from CollabNet presented what is coming in Gerrit v2.12 and v2.13.
Gerrit v2.13 has been the biggest version of Gerrit ever, with over 2,600 commits from 83 different contributors. That shows that Gerrit is an OpenSource project with a growing Contributors’ Community, getting more diverse over time.

There have been a lot of new features and improvements introduced. The most significant and noteworthy features are …

Git LFS

Ability to store large files outside the Git repository to an externally pluggable repository, such as HDFS or AWS S3.

Gerrit Metrics

New extension point to extract in real-time the performance data of Gerrit’s internal activity and publish them externally to Graphite, ElasticSearch, JConsole or other similar graphing and monitoring tool.

Hooks

There is now the ability to replace the dated hook system with much more powerful in-process-plugins. Existing hooks are then still supported using the “hooks” core plugin. Gerrit is getting more modular and extensible.

Improved review of Merge Commits.

Gerrit can implement effective “merge-requests” lifecycle on top of regular code review. You can now create feature branches exactly as you do with GitHub or GitLab and then submit only the “merge request” as change for reconsideration.

What’s cooking in Gerrit v2.14

PolyGerrit

After eight years, Gerrit GUI needed a complete revamp and modernisation, to compete with all the other web-based Code-Review systems such as GitHub, GitLab, and BitBucket.

Google has allocated a brand new front-end Team, located in San Francisco, to redesign and implement a brand-new user experience. It is much more than a simple rewrite; it is a complete rethinking of how to get the most of your code review functionality with the optimal utilization of space.
The new UX will be more fluid and adaptable to different sized screens, including tablets and even smartphones. It will be then possible to give a usable GUI even when accessing Gerrit “on-the-road.”

Suggested Reviewers

Gerrit is getting smarter and, by using sophisticated heuristics, it can now understand and sort the suggestions of which are the people that are most likely to be interested in reviewing a change. Gerrit allows saving time in browsing for individuals and contributes to the accuracy of the reviews.

New HTML e-mails interaction with Code Reviews

Say goodbye to long ugly diffs in e-mails, and now you can generate nice and tidy e-mails where all the details are carefully formatted for achieving maximum clarity. Additionally, you will be even able to reply in-line to the comments received via e-mail and Gerrit will be able to capture the message back and insert the feedback as code-review messages into the code carefully.

Robot comments

CI and automated systems can contribute comments to the code, without spamming the overall review discussion flow. That contributes to a much cleaner user-interface.
Google uses automated code analysis tools such as Tricium and ShipShape to capture the most common mistakes in coding and event providing the corresponding suggested fixes. All this feedback will be captured and integrated with Gerrit in the change comments GUI. The Change’s author will then be able to review the suggested fix and apply it with a simple click.

The management of robot commits will be fully operational with the new PolyGerrit GUI.

ElasticSearch Indexes

Instead of using the local Lucene Index, Gerrit would use an external ElasticSearch cluster to achieve maximum scalability and share the index across multiple nodes. That is one of the cornerstone feature needed for a multi-master setup.

A lot of time has been spent in making sure that the ElasticSearch support was aligned with the current Lucene implementation, but unfortunately, it took until v2.14 to fill the gap. Still, there are parts of the index not yet implemented in ElasticSearch, such as the on-line reindexing. Hopefully, the v2.14 will see all those gaps resolved and enable a real multi-master shared index setup.

Atomicity with Change-Sets

Basavaraj Karadakal from Juniper Networks presented a real-life implementation of the “submit whole topic” into his organization. We always said that “topics” require some company-wide naming policy to avoid conflicts and unexpected behaviors: Juniper found the solution by introducing a new concept, the “changeset.”

The name isn’t new to people that have been in the SCM long enough to remember IBM Rational ClearCase. Interestingly Basavaraj used that term, possibly to facilitate the understanding and adoption into the company.

The idea behind change set is to have a single change review “leading” the topic submission, stored in a “tracking repository”. One can understand the list of changesets and their status by querying the “tracking repository”. This feature is fascinating because it allows obtaining a full list of “open topics” inside Gerrit, which isn’t currently available as “out of the box” feature.

The overall implementation of change sets is composed of a set of client wrapper scripts and server-side plugin to orchestrate the review status of the changeset based on the review status of each commit included.

We do foresee a lot of feedback in the community around changesets and topics: the discussion started a couple of years ago and everyone agreed that “something was missing” in the current Gerrit topic concept … possibly the “change sets” are the missing piece of the jigsaw to make the “submit whole topic” a feature ready for production use.

Pull Requests in Gerrit

Since v2.13, Gerrit allows full reviews of merge commits. However, the workflow isn’t visible:

  • create a feature branch feature/abc
  • commit changes directly to the feature/abc branch, without requesting any review
  • once the branch is ready for review, merge into its target branch locally and push the merge commit to refs/for/target-branch

Eryk Szymanski, CollabNet, has presented an alternative GUI to make this scenario, typical of GitLib, GitHub, and BitBucket, more accessible for novice users.

The new Pull-Request GUI is based on two components:

  1. REST API, different from Gerrit’s native ones
  2. Pull-Request GUI, not integrated with Gerrit’s GWT or PolyGerrit but available as components of CollabNet’s TeamForge product.

Gerrit Analytics

Luca Milanesio from GerritForge introduced two new plugins in Gerrit 2.14:

  • Kafka stream events: to consume stream events and send them to topics
  • Project analytics: to crunch data from Gerrit repositories to expose aggregated contributors statistics

The vision of Luca Milanesio, GerritForge, is splitting Gerrit statistics into three dimensions:

  • People. What is the list of contributors, maintainers, reviewers? What do they do, how often they commit and which ones are the most active influencers?
  • Projects. How repositories are evolving over time and space and what do they need moving forward regarding storage and performance?
  • Systems. How is Gerrit behaving concerning CPU, Memory, and Network utilization?

The correlation of the metrics collected in these three dimensions allows putting together the KPI that allows understanding better how Gerrit is used and how to improve its current and future performance.
Additionally, you could use them to reward and promote good practices of code-review and fuel continuous innovation across the teams.

In one sentence, Gerrit Analytics will allow to “uncover the hidden value of your Gerrit Code Reviews”.

Plugins for CI Systems

Martin Fick from Qualcomm Innovation Center gave an overview of three new plugins developed for use by CI systems: the batch, manifest, and task plugins, with some modifications to the Gerrit core needed.

The batch plugin provides a mechanism for building and previewing sets of proposed updates to multiple projects/branches/refs that should be applied together. The focus of batch updates tends to be verification (by CI systems). The batch update service provides the tools to build refs by merging changes to temporary “snapshot” refs, which can then be tested extensively, and finally submitted ”as is.”
That represents a different approach to resolving the “topic submission” problem: Martin’s plugin would work for all Gerrit versions from v2.7.

The manifest plugin provides server-side utilities to operate on, and query information about repo manifests (XML) stored in git projects on the current server. This plugin provides APIs to update values in manifests, and to search for manifests with certain values.

The task plugin provides a mechanism to manage tasks which need to be performed on changes along with a way to expose and query this information. Tasks are organized hierarchically, and their definitions use Gerrit queries to define which changes each task applies to, and how to set the status criteria for each task. An important use case of the task plugin is to have a common place for CI systems to define which changes they will operate on, and when they will do so.

Gerrit CI Pipeline

Gerrit has finally a fully-feature CI Pipeline, thanks to GerritForge who invested time and resources to set up the https://gerrit-ci.gerritforge.com web-site.

During the Gerrit Hackathon 2015, Luca Milanesio, Doug Kelly and Khai Do have put together their ideas and skills to introduce an entirely automated and community-driven Jenkins set-up which allows to automatically generate the build jobs from the YAML files archived in the Gerrit-ci-scripts project.

The magic behind the system is that nobody directly controls the definition and execution of the jobs, but it is the collective contribution and code-review of the YAML files that automatically re-configure the Jenkins instance automatically.

Over 30K builds were executed last year, with an average of over 80 builds per day. Thanks to the Gerrit CI it is now possible to discover which plugins are available and stable on different branches of Gerrit and download the pre-built artifacts with a simple click.

What is still missing is an official “distribution site” of the Gerrit plugins; a place where successful plugin builds are installed on real Gerrit instances, tested and released. GerritForge is investing time and money to fill the gap and will provide a premium service called “Gerrit Central” available as an add-on to existing Enterprise Customers. The resulting fixes coming from this process of plugins validation will be contributed back to the community and will be accessible for everyone.

Gerrit Bazel build: a farewell to Buck

From v2.14 Gerrit is moving away from Buck and, after eight months of work of efforts for migrating the build system, David Ostrovsky has finally announced that the build is green and we are ready to move to Bazel, yeah.

Building Gerrit isn’t an easy task, with 35 repositories, 400K Java + 16K JavaScripts lines of code, over 140 dependencies and a complete JavaScript toolchain based on NodeJS. In addition to that, there are over 100 plugins automatically built with our CI system hosted and managed by GerritForge.

Gerrit started initially with Maven, but it was very slow and clumsy. After the London Hackathon in 2013 the project was successfully migrated to Buck, which promised to be much faster and flexible. However, this choice has driven the project build to a swamp of problems and bugs/fixes needed on top of Buck to make the build work.
As a result, a custom version of Buck needed to be built using Ant for potentially every branch of Gerrit development. The Gerrit project has submitted over 100 bugs to the Buck project over the three years of adoption.

Bazel is an OpenSource build tool based on an internal system used in Google and is much more advanced and stable, offering a simpler installation and an advanced sandboxing capability to isolate builds and results.
Differently from Buck, Bazel promises both speed and accuracy, qualities that were not always present at the same time.

During the Hackathon, David posted a milestone change named “Remove Buck build” which is currently under review. We all hope that the change will be merged very soon and give the final farewell to Buck build, and our thanks for having helped and supported us in our journey for over three years.

Gerrit reviews from e-mails

Patrick Hiesel from Google presented a very innovative feature that extends the ability to interact with Gerrit reviews by just answering to e-mails.

The feature is still in the very early stages of development  but the demo showed at the Summit was impressive. When you receive the e-mail notification from Gerrit with the comments of people to your code, you just answer in-line to the e-mail and … the magic happens! Gerrit fetches the e-mail automatically and understands the in-line replies as comments to be added to the reviews.

This new workflow dramatically reduces the cycle time of interactions during the review and represents IMHO the “killer feature” to push Gerrit to the top of the Code Review systems currently on the market.

Let me recap what you have to do currently with Gerrit:

1. Receive a notification e-mail
2. Read the comments
3. Click on the change link
4. Open a browser at the change page
5. Sign-in (assuming that you are using PolyGerrit, it would work on Mobile too)
6. Locate the comment you wanted to reply
7. Click on the comment
8. Click on Reply
9. Enter your Reply
10. Click save
11. Go back to the main change screen
12. Click on Reply
13. Click on Post

… and with the inbound e-mail ingestion in Gerrit it will be:

1. Receive a notification e-mail
2. Read the comments
3. Click on Reply
4. Insert your replies in-line
5. Send

There are issues, though, mostly related to security and trustworthiness of the e-mails as the vehicle for reviews.
We know that e-mails can be SPAMs or can be forged by faking source e-mail addresses. Currently, the prototype shown was only matching the e-mail sender to associate to the reviewer identity, which is fine for the majority of the cases but could raise some concerns regarding compliance.

The reviews coming from e-mails will be appearing with a different style and will be noticeable compared to more secure web-based comments. That would allow judging the comment accordingly and avoid over-reliance on their value.

It has been suggested as well to consider the integration of PGP-signed emails and the matching of the PGP-Key with the one stored in Gerrit for that user: that would be the perfect secure solution to avoid SPAMs or forged e-mails risks. However, Patrick did not commit to implementing the feature at this level for the initial MVP.

Inbound e-mail processing is a feature to keep under the radar as it will cause a wave of adoption of Gerrit because of the speed-up of entire Code Review lifecycle and consequently the time-to-market of the development of projects features.

Keep the conversation flowing with Gerrit at OpenStack

Khai Do, the maintainer of the Gerrit Review at OpenStack, has presented the challenges of managing comments with a large-scale project.

The OpenStack numbers for Code Review are astonishing:

  • Nine servers (1 master + 8 slaves)
  • 1500 repositories
  • 400K changes
  • 20K users
  • 700 events generated every hour

In addition to the scale of the installation, OpenStack allows third-party to connect to Gerrit using stream events and trigger validation builds. This workflow is code-named TCPI at OpenStack. There are currently 180 registered TCPI which generate *a lot* of messages appended to each change under review.

The overload of information associated with a change makes the “discussion flow” hard to follow in Gerrit: each change is swamped by CI messages which make the overall review unreadable.

Khai has developed a plugin that allows avoiding storing all those messages as regular reviews in Gerrit and collect them instead in a relational database. The overall result is then nicely rendered in a different section of the change, making the review discussion visible and flowing again.

The plugin works out of the box on the current version of Gerrit. Well done Khai.

Infinite Gerrit

Haithem Jarraya from GerritForge presented the idea of adopting a much more scalable storage for JGit based on Apache Cassandra. Shawn Pearce experimented the same scenario a few years ago and contributed an initial prototype on GitHub: piggybacking on the same concept, the new experiments are now driven by the need of scaling up Gerrit in space and number of nodes.

Gerrit Multi-Master is getting closer day-by-day, thanks to the joint efforts of all contributors from different points of view:

  • Sessions can be externalized to a flat-file to supports sharing across nodes (Qualcomm contribution)
  • Indexes and Caches can be aligned across nodes through events (Ericsson contribution)
  • ElasticSearch will be soon available as alternate shared indexing engine (Sony & CollabNet contributions)

Haithem now is adding one extra significant piece of the Jigsaw: the ability to have a scalable shared and extensible storage that allows all the master nodes of the cluster to read/write JGit Pack files at maximum speed. Additionally, thanks to Apache Cassandra multi-nodes data sharing and replication. You will be able to dynamically extend and reallocate the size and structure of the storage without impacting the current operations on the Gerrit Cluster.

The Cassandra backend wouldn’t cover the ref-database, which could be implemented with an entirely distributed implementation such as JGit Ketch (still in early development) or a more standard based on Apache Zookeeper.

Accounts and status of NoteDB

The task of migrating all the Code Review meta-data to the Git repository, aka NoteDB, started over two years ago. Edwin Kempin from Google, presented the current status of the implementation, with a focus on the Accounts migration.

In Gerrit v.2.13 there is already a new repository dedicated to the archiving of users, called All-Users. However, some of the information are still stored in Reviewdb, such as the external ids. Accounts will be exposed via REST-API and sensitive information encrypted end-to-end on the repository, using the same technique used for secure.config.

A new “magic ref” concept has been specifically forged for the All-Users use-case: the reference to their branches as refs/users/self. Each user will be able to get its meta-data by only fetching refs/users/self from the All-Users repository; easy isn’t it?

There is still one piece of information that will still stay outside NoteDB: the reviewed flag. The choice was made because of the inherent volatility of the information: NoteDB would have been overkill for a piece of information that lasts a few minutes or maximum hours typically. The default implementation will be H2 but it could be then replaced with something more “multi-master” aware.

What’s left? Gerrit Groups are the very last piece of the jigsaw and then NoteDB will be finally 100% feature complete. Bye bye DataBase, NoteDB is approaching fast!

Zero-Downtime Gerrit Upgrades

Luca Milanesio from GerritForge closed the Summit with a case-study on how GerritHub.io achieved a 100% zero-downtime migration process, with limited disruption to its 10K users.

Apart from Google, the current implementations of Gerrit Code Review around the world do not allow to keep the service running in case of upgrades between major releases. That was true until GerritHub.io recently introduced a well-testing roll-out mechanism inspired by the well known “blue-green” deployment.

The approach adopted by GitHub, in the case of DB upgrades, is to advise the customers up-front and schedule a planned outage of the system. Last time that this happened was last year and the blackout lasted for around an hour. However, GerritHub.io decided to be different and developed a strategy where the old version and the new version can work side-by-side by synchronizing Git repository and reviews, even across different versions of the DB schema and index.

The “preparation phase”, or Step-1 as Luca described it, may take even days or weeks to complete because relies on a low-bandwidth mirroring to avoid service disruption on the current user-base. Once the two instances are aligned, the subsequent steps will take only a few minutes.

During the “flipping” of the blue (old release) with the green (new release) instance, the users will notice that the repositories become read-only and receive a courtesy message saying “Upgrade is in progress, all projects are read-only. Please retry a few minutes later”.

The read-only “service degradation” would last only for a few minutes (2/5 minutes) and wouldn’t cause a service disruption for all the other users that are fetching, cloning or just browsing the reviews.

The Gerrit Hackathon

gerrithackathon-2016

Even though this year we had only two “hacking days,” the overall productivity has been remarkable: 158 changes created, with 82% of them merged during the Hackathon.

Bazel Build

Authors: David Ostrovsky, Luca Milanesio, Edwin Kempin, Han-Wen Nienhuys

Changes: https://gerrit-review.googlesource.com/#/q/project:gerrit+after:2016-11-10+before:2016-11-17+message:bazel

The summary of the changes is perfectly represented by David’s announcement to the Gerrit mailing list:

“I’m pleased to announce, that we are moving from Buck to Bazel build tool [1].
I’m working for a while on the transition now, and we are reaching the feature
parity for Bazel build toolchain.

I think that Bazel is a better tool for us and provides the following advantages:

* all actions are hermetic by design (no arbitrary python code execution)
* bootstrapping doesn’t require Ant
* can be installed on the main operating systems, including Windows
* better support for re-using of build rules across local and remote repositories
* switching to different branches wouldn’t mean rebuilding build tool
* extensible rules
* failed tests are not cached
* flaky tests are re-run multiple times
* error prone static analyzer integration out of the box

I would like to thank Shawn for supporting this project, and reviewers/contributors:
Han-Wen Nienhuys, David Pursehouse and Damien Martin-Guillerez from Bazel team.

Also big thanks to Luca and GerritForge for helping out with the CI and running a *lot* of tests.
Here is my related talk from Gerrit User Summit 2016: [2].

[1] https://bazel.build
[2] http://ostrovsky.org/gerrit/bazel-build-gerrit”

Allow plugins to define “has” search operands

Author: Martin Fick

Changes: https://gerrit-review.googlesource.com/#/c/91514/

Plugins can define new search operands to extend change searching.
Plugin methods implementing search operands (returning a
`Predicate<ChangeData>`), must be defined on a class implementing
one of the `ChangeQueryBuilder.ChangeOperandsFactory` interfaces
(.e.g., ChangeQueryBuilder.ChangeHasOperandFactory). The specific
`ChangeOperandFactory` class must also be bound to the `DynamicSet` from
a module’s `configure()` method in the plugin.

The new operand, when used in a search would appear as:
operatorName:operandName_pluginName

A sample `ChangeHasOperandFactory` class implementing, and registering, a
new `has:sample_pluginName` operand is shown below:

 @Singleton
 public class SampleHasOperand implements ChangeHasOperandFactory {
 public static class Module extends AbstractModule {
 @Override
 protected void configure() {
 bind(ChangeHasOperandFactory.class)
 .annotatedWith(Exports.named("sample")
 .to(SampleHasOperand.class);
 }
 }

@Override
 public Predicate<ChangeData> create(ChangeQueryBuilder builder)
 throws QueryParseException {
 return new HasSamplePredicate();
 }

Zoekt

Author: Han-Wen Nienhuys

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-11-10+project:zoekt

Han-Wen has officially announced at the Gerrit Hackathon, the general availability of the Zoekt code search engine.

“Hi there,

I’d like to announce “zoekt”, a search engine for source code I wrote over the last month or so. It was made to work well with (large) Git based repositories, so I think some of you may find it useful.

If you’re interested in code search, please try it out, and let me know about your experiences.

http://github.com/google/zoekt
http://gerrit.googlesource.com/zoekt

I didn’t do any work to try and integrate it with Gerrit/Gitiles, but
if someone wants to invest effort in making that happen, I’d be
happy to review CLs. “

ElasticSearch Index

Authors: Hugo Ares, Dariusz Łuksza

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-11-10+project:gerrit+message:elasticsearch

Small steps towards the goal of having ElasticSearch integrated as Gerrit secondary index:
– On-line reindexing (in-progress)
– Accounts indexing (in-progress)

Plugin examples

Author: Martin Fick

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-11-10+project:plugins/examples

Gerrit cookbook has become over the years a mix of different type of plugins functionality. That is good and bad at the same time. A typical “cookbook” should have a set of recipes for obtaining a final dish ready to eat … whilst our was more like a mixed salad with a bit of everything.

Martin started the noteworthy task of reorganizing the cookbook in a set of self-contained example, hopefully,  easier to manage and with a clearer understanding.

Cassandra Repository Manager

Author: Haithem Jarraya

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-11-10+project:libs/modules/repomanager/cassandra

Haithem started a new change (still in draft at the moment) for plugging an alternative JGit DFS implementation to the Gerrit repositories. It is the very first time that such a challenging goal is attempted outside Google data-centers and BigTable/GFS infrastructure. If we succeed in completing the implementation and demonstrating that the resulting architecture is more robust and scalable than the local file-system, it would be a first 100% OpenSource distributed JGit backend ever.

Gerrit LibModules

Author: Luca Milanesio

Changes: https://gerrit-review.googlesource.com/#/q/message:libModule+after:2016-11-10+project:gerrit

Luca discussed how to “plug” an external repository manager into Gerrit: it is something “similar” to a plugin but more fundamental to the system. Differently from a plugin, it needs to satisfy the following requirements:

  • Loaded at start-up time only
  • Cannot be unloaded
  • Must be injected in the primary Gerrit sys injector

It is not the first time that we need to introduce a “modular piece of software” which isn’t part of Gerrit Code Review:

  • Java CryptoProvider – BouncyCastle
  • Encrypted secure store for gerrit.config
  • Servlet filter for authentication and SSO
  • JDBC Interceptor for JavaMelody
  • Multi-hosted Git repository directories

Instead of creating “yet another exception” in Gerrit, we discussed amongst the hackathon members and agreed to come up with a new concept: LibModules.

The rationale behind the name is:

  • They need to be loaded from the same Gerrit class path from /lib
  • They provide extra Guice modules to be added to the sys injector at start-up

The configuration of a set of LibModules in Gerrit is straight-forward:

[gerrit]
installModule = com.mycompany.MyModule
installModule = com.googlesource.gerrit.modules.FancyModule

Now that the change is merged and the new concept has become part of Gerrit, we are expecting a growing number of LibModules to become available.

Removal of references to LocalDiskRepositoryManager

Authors: Hugo Ares, Shawn Pearce

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-10-11+project:gerrit+message:LocalDiskRepositoryManager

Shawn and Hugo started removing the explicit references in Gerrit to the local filesystem for resolving Git repositories. Those changes are needed to fully support an alternative implementation of a Repository Manager not based on a local filesystem anymore.

DynamicBeans for Gerrit Plugins

Author: Martin Fick

Changes: https://gerrit-review.googlesource.com/#/q/before:2016-11-17+after:2016-11-10+project:gerrit+message:DynamicBeans

Until now it has been possible to create new SSH commands or REST API through plugins, which is great but sometimes not enough. Martin came up with a use-case where they need to rather extend the current core commands, without having to necessarily change its code. How can you satisfy this use-case with plugins? Martin has the solution and is called “DynamicBeans”.

It is definitely an interesting use-case that is going to trigger a lot of interest and discussions amongst the Gerrit Community.

Analytics plugin

Author: Luca Milanesio

Changes: https://gerrit-review.googlesource.com/#/q/after:2016-11-10+project:plugins/analytics

One of the things that people are missing in Gerrit, when comparing it to GitHub, is the overall repository statistics:

  • List of contributors with number of commits / adds / remove
  • Project’s statistics of number of commits over time

The new analytics plugin extends the Gerrit project’s SSH and REST API to expose aggregated data extraction. It is extremely fast compared to GitHub because it works purely in streaming and doesn’t actually load the data in memory. The amount of data generated by the analytics can be huge and is intended to be used by an external analysis and dashboard system. Differently from the typical Gerrit’s API, the returned result has one item per line instead of a big unique JSON object. The rationale is that to generate and process a set of JSON elements in streaming, you need to make each record self-contained and processed independently. That would allow as well batch-processing with a parallel system, without having to parse the entire file content all at once.

Example of how to extract the list of contributors out of a Gerrit project via SSH:

$ ssh -p 29418 admin@gerrit.mycompany.com analytics contributors

{"name":"John Doe","email":"john.doe@mycompany.com","num_commits":1,"commits":[{"sha1":"6a1f73738071e299f600017d99f7252d41b96b4b","date":"Apr 28, 2011 5:13:14 AM","merge":false}]}
{"name":"Matt Smith","email":"matt.smith@mycompany.com","num_commits":1,"commits":[{"sha1":"54527e7e3086758a23e3b069f183db6415aca304","date":"Sep 8, 2015 3:11:23 AM","merge":true}]}

Wrap-up and Summit in 2017

It has been a very intense and revolutionary Gerrit User Summit & Hackathon this year, with a lot of new faces, new contributors and new features coming in the next forthcoming releases.

At the summit, Shawn Pearce and Luca Milanesio announced the proposal to organize the event in Europe for next year, possibly in June/July or Oct/Nov 2017. The reason for changing the location is to attract the feedback from more Gerrit Users that have not been heard so far and increase the participation of the community in the future of the of Project.

The summit has been already endorsed by the major organizations driving the Gerrit Code Review Project and other very active sponsors of the OpenSource Community, including CloudBees, CollabNet, eSynergy, Google, GerritForge, SAP and SkillsMatter which has offered to host the event at CodeNode.

Shawn Pearce, the Gerrit Code Review project founder, will send in the next few weeks a Survey to capture the opinion of this proposal from the Gerrit Community.

See you in 2017 for new and amazing features coming on Gerrit Code Review.

Luca Milanesio – GerritForge.

 

 

 

 

 

 

Gerrit User Summit 2016: Ten days to go

gerritforge-keepcalmandcodereview-copy

In ten days time, the 2016 Gerrit User Summit will open its doors at the Googleplex Campus in Mountain View – CA.

It is going to be an amazing event, with a lot of exciting updates from the Gerrit Community, thanks to the number of innovations that are coming into the platform, from large files support (Git LFS), HTML5 Polymer-based new UX, NoteDB, multi-master updates and a lot more.

GerritForge will be present with five attendees and six amazing talks, covering many of the aspects of the world of Code Review and Continuous Delivery Pipeline:
Code Review Analytics
High Availability and Zero-Downtime upgrades
Infinite scalability with Gerrit on Apache Cassandra
Jenkins 2.0 Continuous Delivery pipeline for Gerrit
Speeding up builds with Bazel on Gerrit
Robot feedback management for Gerrit

Once again, as we always did in the past, we continue to fuel new ideas and innovation to the world of Code Review, with the feedback from the Gerrit User’s Community and developing the ideas as OpenSource, always.

See you soon at the Gerrit User Summit 2016.

Code Review Analytics at Gerrit User Summit

I love hiking mountains; I always did since I was a child. There is a mix of challenges, enthusiasm, and learnings in walking for long hours through little and tortuous steep trails: it challenges your mind and body and makes you stronger.

One thing that always fascinated me is how the shape of peaks and valleys changes as you go higher and raise your perspective. When finally, exhausted, you reach the mountain peak you have a mix of pleasure and relief. You have achieved your goal, and you can, at last, have the full view on the horizon, understand how mountain chains are linked together, where rivers start and end up in lakes, and you can see far away as never before.

Continuous Delivery is a landscape of rivers, lakes, and mountains

I believe today’s landscape of Software Engineering is very diverse: there are so many powerful tools that generate streams of data continuously, and we need to get on top of them every day to be successful in an ever-evolving market space.
Continuous Delivery is the key methodology that nowadays allows the entire “software production chain” working smoothly. However, it poses challenges which are not always technical but often related to the flow of information across the systems and people.

See the big picture

To succeed, we need to raise our point of view to see the “big picture” and understand how things are connected and where are the improvement points, considering all the data we have about:

  • Tools
    collect software and system metrics, logs, test results, build trends
  • Projects
    repositories, commits, branches, pull requests, patch sets
  • People and Teams
    active and passive collaborators, contributors, reviewers, comments and replies

Collecting data is not enough, we need to raise our point of view and hike the Continuous Delivery mountain of problems and reach a point where all those elements make sense because they are:

  • all visible from a single perspective
  • correlated
  • aggregated

Yet another BigData problem

The problem is too many data sources to manage.
The typical solution to the problem is taking all logs from everywhere and publishing them to a single repository using an ELK (ElasticSearch + Logstash + Kibana) stack and building fancy dashboards. I have used this approach for small-scale projects, and it works quite well, but … when I tried to scale that to a much bigger Continuous Delivery pipeline the complexity, diversity, and granularity of data just killed my ability to see the “bigger picture” and I felt almost helpless in front of my Kibana dashboards.

Back to the source of data

Trying to understand what was missing, I ended up realizing that some of the dimensions were not taken into account and correlated: Code Reviews.

All the tooling were about test results, build, system and application logs but none of them has taken the code into account, which is the source of all the pipeline. You can understand where to go if you realize where you are coming from: the code is the source of all build chains.
When I started collecting data from the code repository and reviews, all made sense again, and I felt the I have reached the peak of my Continuous Delivery hiking effort: all made sense again and I could see the overall perspective.

Continuous Delivery Analytics

Exactly in the same way we Application Analytics are used to collecting data about our production system, split into dimensions and analyzed, we need then to start doing the same with our Continuous Delivery pipeline.

There are already some of the tools out there in the market which integrates some parts of it, but I haven’t seen a single one who can give you the bird’s eye perspective you need to understand the big picture.

That’s why I started writing one, using the only way make sense for me: writing in the open and with the help and cooperation of the OpenSource community of people and companies who share the same problem and have the same perspective.

Gerrit Analytics coming at the User Summit 2016

I presented my ideas at a couple of conferences (Devoxx, JenkinsWorld) and I received a lot of appreciation and feedback: the next one is the Gerrit User Summit in Mountain View – CA.

Large companies like SAP, Qualcomm, Ericsson,  Google and Intel are exchanging every year their problems and ideas on how to make their Continuous Delivery Pipelines smoother, better and faster.
The perspective will be, of course, more Gerrit Code Review centric with more data and views that make sense from a review perspective.

Call to action

Come to the Gerrit User Summit 2016 in Mountain View – Google HQ on the 12th and 13th of November, and see the Gerrit and Continuous Delivery Pipeline in Action.

The event is FREE, register now at https://goo.gl/forms/oeEnQweHl2noNSnn1

 

Gerrit Summit 2016 is coming

google

Four weeks from now, the eighth edition of the Gerrit User Summit will open its door at Google HQ in Mountain View – CA, 12th-13th of November 2016.
It has been a long journey since the first GitTogether in 2008, and after the split between the Git[Hub Universe] summit and the traditional “unconference” style Gerrit event at Google’s, things have changed quite a lot. While Gerrit remained a 100% OpenSource user-centric project, GitHub has attracted $350M in VC, and they have been losing traction over the years to join the unconference-style events.

What’s new this year?

For the first time, the proposals of talks to the Gerrit User Summit are submitted in Gerrit directly (yeah!) on the summit/2016 repository.

The list of currently approved talks is available by searching for “status:merged project:summit/2016” (https://gerrit-review.googlesource.com/#/q/status:merged+project:summit/2016)
The talks awaiting review are under “status:open project:summit2016” (https://gerrit-review.googlesource.com/#/q/status:open+project:summit/2016)

How cool is that? I foresee already a Doodle plugin for Gerrit 😉

How to register for the User Summit?

Shawn Pearce has prepared a Registration Form for you to sign-up to the event:
https://goo.gl/forms/oeEnQweHl2noNSnn1

Once you access the Registration Form at the above URL, you need to sign-in with your Google Account credentials and then complete the following information:
– Your name
– Your Organisation
– Your previous attendance to the user summit
– Any dietary restrictions

The User Summit is FREE for EVERYONE, including novice users of Git and Gerrit Code Review, but you would need to register beforehand.
The Summit is a unique opportunity to learn about Gerrit new feature, contribute to the product roadmap with your needs and requirements and, most of all, network with other users to learn new use-cases where Gerrit can be very helpful.

How to submit my talk proposal?

Well, you need to demonstrate a good understanding and use of Gerrit Code Review if you want to teach and talk to other people about it! At the end of the day, if you want to talk about Gerrit you should be able to clone a repository and submit a patch to a project 🙂

If you need just a little help … see my “Diffy super super talk” example:

$ git clone https://gerrit.googlesource.com/summit/2016 && (cd 2016 && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://gerrit-review.googlesource.com/tools/hooks/commit-msg ; chmod +x `git rev-parse --git-dir`/hooks/commit-msg)
$ cd 2016
$ cat - > sessions/my-amazing-talk.md
# My amazing talk at Gerrit User Summit

Hi folks, this is my super-duper-talk. You should be interested in it as I will unleash the dark force of Code Review Diffy Kung Fu Review Cuckoo.

*Diffy, Birds & CO. Inc.*
^D
$ git add sessions/my-amazing-talk.md && git commit -m "Diffy super-duper talk"
$ git push origin HEAD:refs/for/master

Talks highlights.

There are already some fascinating talks submitted and approved and more will undoubtedly come in the next couple of weeks. We will start sharing some highlights of what’s happening at the conference. Here is the overview of the first talks.

What’s new in Gerrit 2.12 and 2.13

Two major versions of Gerrit have been released since the last summit in 2015, and they contain significant improvements to the platform:

  • Topic submission workflow – aka Git commits across repositories  (v2.12).
    Group multiple changes in a “topic” and having them merged as a whole, even across multiple repositories, in a single submit operation.
  • GPG signed pushed verification (v2.12).
    Allows people to upload their GPG public keys into Gerrit and have them used to verify Git signed commits.
  • Large File Storage support (Git LFS) (v2.13).
    Gerrit finally supports the automatic management of large files outside the Git repository. The feature is fully pluggable and exposed via plugins. Amazon S3 and Local file system support are available at the moment, but more plugins are here to come on this feature.
  • Gerrit metrics (v2.13).
    Expose the internal metrics to external consumers. The feature is exposed for plugins to gather this data and send to external systems for analysis and visualization purposes. Graphite, ElasticSearch, and JMX plugins are available.
  • Hooks plugin (v2.13).
    Finally, the Gerrit hooks mechanism have been entirely externalized and implemented in a pluggable way. The legacy hooks have become a core plugin. However, you can now leverage the new extension to develop a new-generation of hooks by leveraging the new extension points provided.
  • New HTML5 UX with WebComponents – PolyGerrit preview (v2.13).
    The next generation of Gerrit UX based on Polymer Web components is available. Even though not complete, offers a sneak preview of what the new interface looks like and, if you like it as-is and is good enough for your use-cases, you can enable and start using it already. Both GWT and Polymer-based UX are using the same REST API, and thus the changes generated and reviewed with them are 100% interoperable.

There is more to come.

In the next few days we will keep on publishing the highlights of the topics coming at the Gerrit User Summit this year, stay tuned and REGISTER NOW at:
https://goo.gl/forms/oeEnQweHl2noNSnn1

The GerritForge Team.

How to Migrate a Git Repository

When and why?

We wrote yesterday about the GitEnt-Scm.com shutdown due on April 30th, 2016. Now the issue you would be facing is: how to migrate somewhere else?
Although StackOverflow already contains over 800 response threads when asking this question we thought that giving a practical example based on a real-life GitEnt repository would allow you to avoid the trial & error discovery.

Step 1 – Mirror clone

When you want to clone a repository for the purpose of migration, you really want everything, including all the other refs that are not branches:

  • Git Tags (refs/tags/*)
  • Git Notes (refs/notes/*)
  • Gerrit Reviews (refs/changes/*)
  • Gerrit Configs (refs/meta/*)

Instead of using a standard clone, you can do a “git clone –mirror”, which implies –bare and thus does not generate a working copy.

Example:

$ git clone --mirror ssh://myuser@gitent-scm.com/git/myorg/myrepo.git
Cloning into bare repository 'myrepo.git'...
remote: Counting objects: 109, done
remote: Finding sources: 100% (109/109)
remote: Total 109 (delta 19), reused 83 (delta 19)
Receiving objects: 100% (109/109), 66.42 KiB | 0 bytes/s, done.
Resolving deltas: 100% (19/19), done.
Checking connectivity... done.

Step 2 – Create empty repo on the new Git Server

You need to have an empty target repository where to push your mirrored local clone. Note that most of the Git Servers propose you to create a first master branch with a README, but, in this case, you do not need it and it would only create more trouble in your migration path.

Example for GitHub:

– Go to https://github.com/new and create the ‘myrepo’ repository
– Do not tick any of the suggested README or LICENSE auto-generation
– Once the project is created, GitHub provides you with the repository Git URL (e.g. git@github.myorg/myrepo.git)

Step 3 – Push to the new Git Server

You are now ready to push to the target repository, and we can use the useful option “–mirror” again.
Similarly to the clone, “–mirror” automatically include all refs, including the non-branch ones (tags, notes, reviews, configs, …); it provides the behaviour of removing all the refs that are not present in your local clone. You should never use this option when you have a “regular default clone” as you would risk removing all the remote refs that have not been typically cloned with a standard default “git clone” operation.

Example for GitHub:

$ git push --mirror git@github.myorg/myrepo.git
Counting objects: 109, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (61/61), done.
Writing objects: 100% (109/109), 66.42 KiB | 0 bytes/s, done.
Total 109 (delta 19), reused 109 (delta 19)
To git@github.myorg/myrepo.git
* [new branch] refs/changes/02/802/1 -> refs/changes/02/802/1
* [new branch] refs/changes/03/803/1 -> refs/changes/03/803/1
* [new branch] master -> master
* [new branch] refs/meta/config -> refs/meta/config

Step 4 – Import into GerritHub.io (Optional)

Your repository has not been fully migrated to your new target server. If you wish now to keep on using Gerrit Code Review for your Development Workflow, you can link your repository to Gerrit using GerritHub.io

The YouTube Video explains how to perform this last operation using GerritHub.io import Wizard.

Need more help?

Do you require more help? Contact our Sales Departement at sales@gerritforge.com and we will provide the extra support you need or perform the migration for you to GerritHub.io.

GitEnt-scm.com Farewell

An open letter to all GitEnt-Scm.com users

it has been a fantastic journey to launch and see the GitEnterprise service growing over the past five years.
We announced the availability in 2011 of a new Enterprise-grade service ahead of other major competitors such as CollabNet or Atlassian. We were the only real Enterprise-Ready Git service much more advanced than GitHub and well before the birth of GitHub:Enterprise.

Since then, over 5000 people used and loved our service and enjoyed a fully FREE and compelling Git server, powered by Gerrit Code Review, the major OpenSource platform code for Code Review on Git.
We are grateful for your trust and confidence in us.

From premium service to commodity

Times have changed, what was considered a premium had become a commodity and services like BitBucket started to erode our take up in the past three years. We moved on to a different and more compelling level of services, jumping again on the edge of innovation and moving into Code Review and its integration with the Continuous Delivery pipeline. We launched in 2013 a brand-new service called GerritHub.io which is now the reference point for major OpenSource and Commercial organisations such as IBM, Cisco System, RedHat and Rackspace.

We continued to maintain both GitEnterprise and GerritHub.io so that you did not have to face any migration or disruption; however the audience of GitEnterprise has become so marginal that we have unfortunately decided to shut down the service within the next 30 calendar days.

The choice: Red or Blue pill?

You have two options, either stay on the cutting edge technology and jump to GerritHub.io or moving to a free commodity service.

Option 1 => migrate to GerritHub.io

Option 2 => moving to another Git provider, such as BitBucket or GitLab.

If you decide to go for Option 1, we invite you to watch the GerritHub.io video on YouTube  and decide whether you would like to start adopting Gerrit Code Review workflow, bearing in mind that it may actually change the way you interact and manage your Git repositories.

Should you need our help in migrating your repositories, we can offer our bolt-on support services at a 10% discounted rate. See www.gerritforge.com/pricing for all the options available and costs involved.

Time is running fast: ACT NOW !

You do need to take a decision before the 30th of April 2016, as after that date the GitEnterprise.com and GitEnt-SCM.com will just redirect to our GerritForge Website and your repositories will not be accessible anymore.

Thank you again for those five fantastic years and for believing in us.
We hope you will decide to continue your journey with us.

Should you have any doubts, please do not hesitate to come back us.

The GerritForge Support Team.

Gerrit Upgraded with No Downtime

Screen Shot 2016-03-21 at 20.48.12

Zero DownTime success story.

From today at 08:06 GMT GerritHub users are served by our brand new infrastructure geo-located in Canada, Quebec, Beauharnois. It is the first time we applied a zero-downtime roll-out scheme, the PingDom uptime for the past 24h reported 100% uptime and 688 msec average response time for the page of the list of opened changes. The two response times spike on the above graphs are actually due to the old German infrastructure and happened before the start of the roll-out.

We can see the switch of the traffic to the new infrastructure from the increase of the overall response time (IP packets were routed from Germany to Canada causing extra hops); as the DNS propagation was spreading across the world, the overall number of hops gradually came back to normal.

Timeline of the events.

  • 08:00:00 GMT – Phase 1 – Set Gerrit READ-ONLY. All changes and Git repositories started to refuse push and updates.
  • 08:00:01 GMT – Phase 2 – Wait for pending replication to complete. Replication queue was empty; there was no need to wait.
  • 08:00:02 GMT – Phase 3 – Mirror DB and Git for the last time, delta-reindex, DB upgrade and Gerrit restart. It has been the longest part of the roll-out and lasted 5′ 32”, aligned with our estimates.
  • 08:05:34 GMT – Phase 4 – Cache warm-up. 20K projects, 8K accounts and 4.6K groups were pre-loaded in Gerrit. This step was optional but allowed us to redirect all the traffic without risks of causing thread spikes on the new infrastructure.
  • 08:06:23 GMT – Phase 5 – Redirect traffic to the new infrastructure.

Did anybody notice the rollout?

During the rollout the Git projects and Gerrit changes were read-only for 6′ and 23”. According to the logs, 493 Git/HTTP and 172 Git/SSH invocations were made and completed successfully: none of them failed.

What is the situation right now?

The new infrastructure public IP (192.99.233.76) has almost completed his DNS propagation around the world, the only countries not entirely covered are Australia and China. The rest of the world is coming directly to Canada avoid the German hops. Metrics are good, low CPU utilization and threads consumption compared to the old German infrastructure, symptom of the reduction of the execution and serving times and latency.

What’s next?

From now on we will continue to use this Blue/Green roll-out strategy, possibly improving in the ReadOnly window by introducing live distributed reindex and cache warm-up.

We fully commit to Zero-Downtime and Stability, the most valuable assets for our clients.

GerritHub and Zero-Downtime Upgrade

GerritHub gets bigger on Mon, 21 March 08:00 GMT


GerritHub has experienced unprecedented growth over the past two years. The November 2015 numbers presented at the Google User Summit in Mountain View – CA have been surpassed again, and we do need to make sure that our infrastructure is still capable of dealing with current and future users’ needs.

What is changing in GerritHub.io?

We are changing everything, from the version of Gerrit to the hardware, network and storage infrastructure. Data, DBMS, Indexes and cache, need to be upgraded and refreshed to make sure that the new systems are reflecting exacting the current production data and sessions.
We are changing as well the geo-location of our servers, from the current server farm in Germany (Bayern, Nuremberg – 100 MBps) to a new server farm in Canada (Quebec, Beauharnois – 1 GBps).

Why have so many changes?

We started to measure some significant delay in the Git and review operations on the old infrastructure, mainly due to three factors:

  1. More users, more repositories, more concurrency. Individuals, OpenSource projects and Businesses started using GerritHub.io for their mission-critical repositories, considering Gerrit the “source of truth” of their review workflow. We needed more horsepower, memory, storage and ability to scale even further.
  2. Bandwidth from USA and Far-east. The majority of people using GerritHub.io are from the other side of the Atlantic Ocean: this is typically not a problem from 7 AM to 3 PM … but after 4 PM the connectivity between Europe and the Americas becomes slow. Additionally, people using GerritHub.io from India, Japan, Australia and New Zealand experienced terrible slowdowns because of the excessive number of hops to reach Germany.
  3. Gerrit master is much faster. Based on the current data and metrics measured on GerritHub.io, we have contributed a lot of patches to reduce the overhead caused by Gerrit DB and lessen the number of SQL queries per minute. All those new improvements are on Gerrit master, and we need to catch-up with the “latest and greatest” version.

Will I experience any GerritHub.io outage?

Last time that GitHub needed to make a major upgrade, asked his 5M users to stop working for 23 minutes,. This translates to a loss of two millions of hours of continuous delivery lifecycle, equivalent to over 130 man/years, worth no less than eight millions dollars.
We are going to adopt a new Zero-Downtime Gerrit roll-out strategy to make sure that all those changes are not going to impact your day-by-day activity. If you were not reading this post you would possibly even not notice the “switch” from the old to the new infrastructure, apart from the increase in speed and bandwidth.

Zero-downtime GerritHub.io migration, step by step with the associated expected timings.

Phase 0 – Replication to the new Gerrit infrastructure. (- 1 month ago)
We started migrating everything one month ago, and the old and new infrastructure are working side-by-side, thanks to Gerrit master-slave replication. The new Gerrit servers are active as slaves and are read-only.

Phase 1 – Migration kick-off. (08:00 GMT)
We install a Gerrit plugin that rejects all the push to GerritHub.io repositories providing a courtesy message: “Gerrit is under maintenance, all projects are READ ONLY”. All the HTTP POST, PUT and DELETE are disable on the Gerrit REST-API.

Phase 2 – Wait for replication events to complete and migrate DB. (08:02 GMT)
Git repositories are continuously replicated, but we do need to make sure that the event queue is empty. Once that happens we schedule the last final DB migration to the new infrastructure.

Phase 3 – Gerrit DB upgrade and reindex (08:04 GMT)
New Gerrit server executes the final upgrade and off-line reindex of the latest received changes.

Phase 4 – Gerrit start-up and cache warm-up (08:05 GMT)
New Gerrit is restarted and the most critical Gerrit caches (projects, accounts and groups) are pre-loaded in memory. This allows the incoming traffic spike to avoid the collapse of used threads and makes the transition as smooth as possible without slowdowns.

Phase 5 – Traffic switch and DNS updates (08:06 GMT)
GerritHub.io redirects all incoming HTTPS and SSH traffic to the new infrastructure. Git pushes and HTTP PUT, POST and DELETE operations of the REST API are operational again and served by the new Gerrit infrastructure. GerritHub.io DNS is updated to the new Canadian IPs.

Phase 6 – New IPs gets propagate to all worldwide DNSs (+ 1 day)
Once all the DNSs in the world would have been updated, everyone will start going directly to the new infrastructure without further hops or redirection from Germany. Customers from USA, Canada, South America, Asia, Japan, New Zealand and Australia should see a significant reduction of the network latency and increase of GerritHub.io responsiveness.

Firewall and SSH considerations

Even if Gerrit server’s SSH key is not changing, some of you may see a warning similar to this when they push or pull over SSH:

Warning: the RSA host key for ‘review.gerrithub.io’ differs from the key for the IP address ‘148.251.77.70’

The warning message will also tell you which lines in your ~/.ssh/known_hosts need to change. Open that file in your favorite editor, remove or comment out those lines, then retry your push or pull.

Should your network have some strict firewall rules to access external sites, you may want to whitelist the IP of the new infrastructure WLB to: 192.99.233.76.

Follow GerritHub.io migration progress.

We will advertise the migration progress on Twitter at @GitEnterprise. Should you have any issue you can tweet us or contact GerritForge Customer Support at support@gerritforge.com.