Continuous Development with GerritForge and Codenvy

On March 22nd, come see Codenvy CEO Tyler Jewell and Gerritforge CEO Luca Milanesio present at Google’s HQ in Mountain View, CA. They’ll cover Codenvy’s continuous delivery system for integrating code reviews, git, and SAAS developer environments in order to eliminate waste in the development workflow.

[…]

Read the full story at Codenvy Blog
[by Eric Cavazos]

More capacity and performance for GerritHub.io

We are pleased to announce that we have successfully completed a new major hardware upgrade to the GerritHub.io platform.

What has been upgraded on GerritHub.io ?

There is a brand new production cluster which provides:

  • More memory (up to 32 GBytes per node)
  • More disk-space (up to 2TBytes per node)
  • More concurrency (up to 8 CPUs per node)

The new cluster is geolocated in Germany / Bayern and provides a much better and stable bandwith.

Do I need to change anything on my client ?

GerritHub.io is accessible from the old and the new IP addresses:

  • old IP address: 94.23.71.44
  • new IP address: 148.251.77.70

The GerritHub DNS is currently propagating the new IP to gerrithub.io and review.gerrithub.io hostnames: during the propagaton time (max 24h) both IPs will provide the same access to the Germany based production cluster.

What about my Git/SSH access ?

When using Git over SSH, the remote host SSH key is exchanged and associated to the resolved remote IP into ~/.ssh/known_hosts file in your local machine. This means that you have currently associated the GerritHub.io SSH public key to the 94.23.71.44 (old IP address).

When the DNS propagation will be completed, you will see a warning from your SSH client asking to verify that the new IP address is OK. In some cases you may be asked to verify and re-accept the SSH public key.

Example of the warning you would probably see on your Git client over SSH:

Warning: Permanently added the RSA host key for IP address '[148.251.77.70]:29418' to the list of known hosts.

Double-check that the IP address shown corresponds to the new GerritHub.io cluster (148.251.77.70). This warning will be displayed only once and then the new IP will be stored in your ~/.ssh/known_hosts file.

GerritHub: code review for GitHub private repositories – early access

Support for GitHub private repositories is making substantial progress: we are proud to announce that the first milestone has been completed and is available for early access.

By using GerritHub on top of your existing GitHub private repositories, you can now define a safer set of commit policies and prevent Git forced pushes on a per-branch basis.

What is exactly GerritHub private repository support ?

With GitHub you can share code with other people and collaborate with the community of developers using public Git repositories on the Web. Your code is public by default and readable by anyone on the Web. This is the most typical case of using GitHub for the development of OpenSource projects.

However sometimes you want to restrict the access to your repository to a limited set of people or teams. Your code is not accessible to anonymous users but only the people you have selected from your GitHub Team security panel. This is typically the scenario of using GitHub for a private business or organisation.

How can GerritHub support private GitHub repositories ?

GerritHub is a public instance of Gerrit Code Review, which provides highly customisable  sofisticated security. Whilst right now all GerritHub projects have shared a common public polity for all projects, you can customise your Gerrit project security and further restrict or extends the default permissions.

What are the benefits of GerritHub on private GitHub repositories ?

By using Gerrit Code Review on top of GitHub private repositories you can improve the security, collaboration and visibility of changes in your development team:

  • Provide a common dashboard with all pending changes on a per-project basis
  • Define validation rules for code to be merged, based on quality, scoring and build validation results
  • Notify people on what is happening on the project’s code
  • Define fine-grained permissions on a per-branch basis
  • Limit collateral damage by blocking accidental force-push on release branches

How can I get early access to GerritHub for private repositories ?

GerritHub for private repositories is FREE for the initial 30 days of early access: it would then be charged at 25% of your GitHub private subscription fee. This means that starting from the 3rd of April 2014 if you are paying  $48/year on your GitHub personal plan, the GerritHub would cost only $12/year.

In order to switch to GerritHub private plan, you need to perform the following steps:

  1. Clear your browser cookies and cache
  2. Login to GerritHub.io using this url:
    https://review.gerrithub.io/login?scope=scopesPrivate
  3. Accept the GitHub modify authorisation screen: you will be requested to grant full access to your GitHub personal profile and public/private repositories
  4. Confirm your GitHub password

How can I import my private GitHub repositories ?

Once you logged in with a private scope in GerritHub, the full list of organisations and repositories are available on your import screen.

You can access the GitHub import screen by choosing the “GitHub” top-menu and “Repositories” entry,
or visit the URL https://review.gerrithub.io/plugins/github-plugin/static/repositories.html

How can I customise my private repository security on GerritHub ?

You are free to use Gerrit Code Review security configuration screen on your imported private repositories, using the “Projects” top-menu, inserting your project name on the search box and select your project. The security configuration is available on the “Access” menu. Alternatively you can access the screen directly using the URL https://review.gerrithub.io/#/admin/projects/organisation/repository,access, where organisation is your username or organisation and repository is your GitHub repository name.

Where can I find more information Gerrit Code Review security and review rules ?

Gerrit Code Review on-line documentation at https://review.gerrithub.io/Documentation/access-control.html provides a very detailed set of information useful for customising your projects security.

Alternatively if you would like a more gradual and descriptive step-by-step guide, the “Learning Gerrit Code Review” book at http://gerrithub.io/book available on Amazon provides an easy and accessible introduction to code review and security.

This is cool, but how can I provide feedback ?

GerritHub is nothing more than Gerrit Code Review plus a collection of selected plugins, including the GitHub integration plugin (see http://www.packtpub.com/article/using-gerrit-with-github). You are welcome to subscribe to the Gerrit mailing list at https://groups.google.com/d/forum/repo-discuss‎ and to the GitEnterprise blog at http://gitenterprise.me.

Comments, suggestions and hints are more than welcome !

What about Enterprise Support with guaranteed SLA on problems and incidents ?

GerritForge Enterprise Support on Gerrit Code Review covers the GerritHub cloud usage on private repositories as well. If you need guaranteed SLA you choose from one of the currently available support plans at http://gerritforge.com/support.

 

GerritHub.io is back on-line

Dear GerritHub.io users,
thank you for your patience, the service is up and running again.

We are currently working to increase the capacity of the service, based on the increasing audience received. Additionally we are working to increase the security and provide an active failover on multiple geo-localised IPs: once the service will be available you will be notified on GitEnterprise.me and on Twitter @gitenterprise.

GerritForge Support Team

GerritHub.io temporarily unavailable

Dear GerritHub.io users,
because of unexpected maintenance activity not dependant on our will, the GerritHub.io service is not accessible at the moment.

Your data is always safe and replicated in real-time to GitHub, including your code under review. Should you need urgently to access your source files you can access them through your GitHub repository associated.

Example:
GerritHub URL => https://review.gerrithub.io/mylogin/myproject.git
GitHub    URL => https://github.com/mylogin/myproject.git

We are  speeding-up the maintenance activity in order to bring the service back on-line as soon as possible: we do apologise for any inconvenience caused by this temporary disruption.

GerritForge Support Team

 

Gerrit User Summit 2014 talks proposals

The list of talks proposed for the next forthcoming Gerrit User Summit in Mountain View has been published.

There are very interesting talks on ideas, extensions and case studies from large enterprises and projects: it is going to again an exciting rendez-vous for all of those interested in SCM, SDLC and Continuous Agile.

See below a distilled summary of the proposed topics:

  • Using Gerrit and Jenkins together for the LibreOffice OpenSource Project
  • How to manage and monitor Gerrit using JavaMelody
  • Extend the GitHub fork & pull-request model using Gerrit Code Review lifecycle and GerritHub.io
  • Extending Gerrit with scripting plugins (Groovy, Jython and Scala)
  • Continuous Development and Code Review with Codenvy
  • Large scale Gerrit installations with testimonials from OpenStack, Yahoo and Ericsson !
  • Integrating and using Gerrit in the Enterprise with CollabNet TeamForge
  • … and new talks are coming over !

Seats are running out quickly but there are still spaces available: you can register now for free to the Gerrit User Summit event:

See you soon at the Gerrit User Summit 2014 !

Gerrit User Conference / Summit – 21-22 Mar 2014

Yesterday Shawn Pearce, Gerrit Code Review project founder, has announced the 4th Gerrit User Conference [+ 7th Hackathon] and Summit at GooglePlex in Mountain View – CA.

The interest in Gerrit Code Review is growing, possibly because of the increase of the Git adoption in the OpenSource and Enterprise and consequently the need of a set of best-practices on how to effectively manage a Git workflow when teams are growing: we do expect many new attendees this year !

Key information for the conference

Dates: Friday and Saturday March 21st-22nd, 2014

Location: GooglePlex – Mountain View, CA

Registration: Pre-registration is requiredspace is limited and registration is first-come, first serve. You can register NOW using the Application Form

Have something to share and present in a talk ?

Talks are open and you can submit your proposal using the Talk Proposal Form. We are expecting again the Gerrit plugins, scalability and the new UX to play an important role in the conference. Share your experience and how you managed to integrate the Code Review process in your Team !

Hope to see many of you at the Conference in March 2014.

Gerrit Code Review or Github’s fork and pull ? Take both !

When searching on Google with the keywords “Gerrit” and “GitHub” you find lots of different links with more questions than answers; see below a selection of the most interesting ones:

And additionally Linus Torvalds, the father of the Git version control, whilst keeping the Kernel source on GitHub, expressed explicitly in his own way what he thinks about Pull Requests.

Google decided to use a different tool than GitHub and developed Gerrit Code Review for managing the community effort of developing the Android Operating System, mainly for two reasons:

  1. GitHub pull requests model wouldn’t have worked for Android: forking the projects several thousands times would have been just unsustainable. Google recognized that early on and Gerrit was developed with the “not like GitHub pull request” requirement.
  2. GitHub is not (and today has no plans to become) OpenSource

There are for sure additional reasons why even today and even if GitHub would decide to become OpenSource in the future a long set of features that GitHub would be needed in order to support a large-scale cooperative project !

What is Gerrit Code Review today ?

Today Gerrit is much more than the Android OS review tool ! There are around 80 contributors  growing over time and from both large industries and OpenSource projects. SAP, Sony Mobile and Qualcomm IC are amongst the most active companies contributing to the tool whilst from the OpenSource community there are LibreOffice, Openstack and Wikimedia.

What is the right choice then ? red pill or blue pill ? Open or commercial ?

We thought about the problem very deeply at GerritForge.com as some of our customers decided to completely quit GitHub, mainly for security and confidentiality reasons but others moved into the opposite direction as well embracing GitHub:Enterprise.

In a nutshell the criteria that drove those customers into one (GitHub) or another direction (Gerrit Code Review) were based on the following aspects.

Security.

  • GitHub: history quite weak because of its architecture mainly based on Ruby (or let’s say a naive implementation based on Ruby, as the language itself is not so weak from a security perspective). Problem was solved but raised many concerns in the industry on how many more security problems are still to be found.
  • Gerrit: completely written in Java and with Security in mind. Large corporations such as SAP, Sony Mobile, Qualcomm and many other enterprises, organisations and non affiliated individuals/volunteers contributed to the review and development of the code-base. OpenSource and community code inspection has always the golden rule for very secure projects (e.g. OpenSSH and OpenSSL are widely reviewed and OpenSource) and code-obsucurity has always been a security anti-patterns.

High availability.

  • GitHub: it has been historically very reliable, especially at the beginning. When it started to become popular and saw its traffic to increase exponentially started to be rather unreliable because of several repeated DDoS attacks. GitHub:Enterprise is a proprietary-locked VM that can be installed on-premises but not on a private / public Cloud.
  • Gerrit: differently from GitHub, it is not a service and can be hosted either on your private / public Cloud or on-premises. Google has some instances in his own distributed cloud network around the world and managed with high availability in mind for Android OS development and other OpenSource projects (and for Gerrit self-hosting of course). Google’s deployment has not been impacted by DDoS attacks so far and its physical deployment is protected by the standard Google DataCenters network security. Other deployments are either private or distributed around different projects’ sites.

Usability.

  • GitHub: the key of the success of GitHub is its amazing user-experience and the ability to push the OpenSource development to a new level of social collaboration ! We all need to be grateful to GitHub for having made the OpenSource development ever more interesting and fun for the masses.
  • Gerrit: the user interface is functional but not “shiny” or “attractive” as a modern social collaboration platform should be. In a nutshell Gerrit does not want to be a developer’s social network but rather targets its specific objective of managing Code and Projects across large teams. This is the reason why large OpenSource communities such as the Eclipse foundation embraced Gerrit.

Scalability

  • GitHub: based on C-Git implementation (using the GitHub libgit2 library) that works very well with small repositories. However when the number of BLOBs and Packs increases the effort of counting them through the repository history grows linearly over time (*). With regards to the number of repositories, GitHub demonstrated to be capable of being very effective in distributing the data cross their nodes and sharing BLOBs for limiting the disk-space needed for forked repositories.
  • Gerrit: the R&D folks working at Google have invested a lot of time in optimising JGit for large repositories and a large number of users accessing them. The latest excellence of their performance improvements is represented by the JGit bitmap implementation (thanks to the fantastic work by Colby Ranger). Those optimisations however are not present in the C-Git code-base used by GitHub. With regards to the number of repositories the largest installation I have ever seen has less than 50K projects: it has never been used or tested with millions of repositories AFAIK.

(*) Note from Shawn Pearce on this topic: “Its just crazy slow per object, the C implementation discovers around 70k objects/second. 3M objects takes 42 seconds at best, the truth is the rate of new object discovery slows as it goes further back in history, which is why counting 3M objects takes modern machines minutes. GitHub has tried porting the bitmap code to C. Its running in some limited cases on their site, at one time https://github.com/torvalds/linux/ had it enabled. We haven’t seen updated patches for it, and it looks like its disabled again.”

Code Review

  • GitHub:  uses the fork + pull model. In a nutshell every user always pushes to its own “forked version” of the repository and, once the changes are ready, request the source repository owner to pull its changes. Works very well for projects where there is a single approver of all the incoming changes and the GitHub user-interface is simply amazing in the way that changes are displayed and navigated in a unified-diffed view making the multiple commits review a simpler task.
  • Gerrit: being designed for projects with many contributors and committers, do not embrace at all the fork + pull model. It would have been simply unmanageable having hundreds of thousands of forked version of Android OS code-base ! The Gerrit workflow is mainly derived then from the Android OS contribution workflow: each contribution is defined as “Change”, has a unique ID (Change-ID) and is composed by a set of Patches (Patch-Set) of candidate changes. When the latest Patch-Set reaches the necessary score to be approved (Code-Review +2 and Validate +1 for the Android OS workflow) then it can be merged.

Why not using Gerrit and GitHub together ?

This is not a new idea as it has been proposed and successfully implemented by some popular OpenSource projects such as:

The benefits of using both tools are twofold.

From the features and performance perspective the projects can benefit from the Gerrit JGit engine and associated Code Review capabilities. Gerrit Code Review model may seem less friendly than GitHub’s Pull Request but eventually generates a more readable and maintainable code-history, essential for long-term products in production.

From the point of view of accessibility and social community, the fact of using GitHub allows WikiMedia and Openstack to have an extended reach and at the same time even off-load all the clone traffic to GitHub nodes instead of their Gerrit servers !

Why GerritHub ? What is the value added by the platform ?

We thought about creating GerritHub about 2 years ago, when we first discussed with Kohsuke Kawaguchi, the adoption of Gerrit for the Jenkins Continuous Integration project. He liked Gerrit at first sight when he joined the Git Together in 2011 @Mountain View but at the same time he was concerned about the loss of reach and ease of use of GitHub.

The integration between the two tools was technical possible but challenging and needed some significant set of Gerrit skills to be implemented correctly, including the integration between the Pull Request model and the Gerrit Code Reviews.

GerritHub is the first Gerrit-powered platform that offers the best of Gerrit 2.8 (current master release) integrated with GitHub SSO (using OAuth 2.0) and replicated to GitHub repositories and Pull Requests. Differently from the WikiMedia and Openstack implementations, it is a self-service platform and anyone who has a GitHub account and repositories can self-register at GerritHub and use it for its own OpenSource projects !

Summary.

There is no winner in the battle between GitHub and Gerrit because they are simply different tools for different audiences. There are cases where the needs are mixed and both can provide a valid platform for the purpose of the projects.

Gerrit has been historically a niche tool, confined to the Android OS development: now things are different and major OpenSource projects adopted it as standard. However the need of a “public GitHub presence” was needed and has been implemented.

GerritHub gives you the choice of taking and using the best of both !

Learn more about Gerrit Code Review and GerritHub.

Gerrit Code Review home:
http://code.google.com/p/gerrit/

One-click sign-In and auto-registration to GerritHub:
https://review.gerrithub.io/login

Book about Gerrit Code Review:
http://gerrithub.io/book

GitHub outage lasted 4h: can your business afford the costs ?

Screen Shot 2013-10-03 at 14.29.20

 

GitHub is finally back, after 4h of outage because of a DDoS attack: we can all come back to push changes and the Continuous Integration Engine (e.g. Jenkins) will start building again.

The problem is: how much money you have lost in those 4h of outage ? 50 Developers at $500/day would have costed over over $12,000 … can your Business cope with that risk again and associated losses ?

Having another mirror, a spare wheel either on-premises or on the Cloud, would cost nothing and allow you to limit your costs in case of another GitHub outage ! Give a try to http://gerrithub.io or install Gerrit Code Review on your premises and protect your Development Team.

GitHub is down, use GerritHub.io replication for High Availability

Screen Shot 2013-10-03 at 11.41.45

 

This morning GitHub is down again, not the first time unfortunately !

If you want to keep using GitHub but NOT being blocked when it is down, you can use Gerrit Code Review replication for having an always up-to-date replica. With the GitHub plugin, your accounts and repositories are always in synch and can be used for failover.

Read how to use GitHub and Gerrit Code Review on http://www.packtpub.com/article/using-gerrit-with-github

If you want to use Gerrit with GitHub on the Cloud, register today at http://gerrithub.io and next time that GitHub will be down, you will not be affected.