Hi Dimuthu, it is your decision and your business for sure ... but approach #2 does not scale and work well :-)
Do you have any Gerrit or Gitblit coding experience ? Luca. On 31 Mar 2014, at 09:02, Dimuthu Upeksha <[email protected]> wrote: > Hi all, > > Currently App Factory doesn't support for code reviewing functionalities. We > are expecting to provide support to integrate existing code review tools to > App Factory. > > Currently available code review tools > > 1. Pre commit tools > Gerrit > > 2 Post commit tools > Crucible > Barkeep > Phabricator > > I initiated a discussion in engineering group mail thread to clarify > requirements. > > Summary. > > App factory should support both types of (post and pre commit) review tools > according to customer demand. > Because these two types work in different workflows it is required to > consider them as two separate requirements. > Gerrit is one of the most popular review tools. So as the first phase I'll > integrate Gerrit with app factory. > > Currently app factory uses Gitblit as the git implementation to manage Git > repositories. > > Gerrit uses it’s own local repository to handle code reviews > > If we need to integrate Gerrit as a code review tool for App Factory, there > are two approaches > > 1. Remove Gitblit and replace Gerrit with Gitblit plugin. This acts as a > git management tool and a review tool at same time > > <Approach_1.png> > > Pros > > Conceptually simple to manage git repositoris and reviews because all are in > an one implementation > > Cons > > App factory has its own server side git hooks written in Gitblit. In this > scenario because Gitblit act as a plugin inside gerrit, those hooks may not > work. So we need to write hooks to gerrit to do that work > > Need to do considerable amount of architectural changes in repository > creational phase. This avoids from providing support to integrate other > review tools because repository creation is tightly coupled into Gerrit > architecture > > > 2. Keep Gerrit as default App Factory implementation and connect Gitblit’s > git repository to a separately hosted Gerrit server > > <Approach_2.png> > > In this case Gitblit runs separately and Gerrit runs separately. Only > connection is the shared repository. > > Pros > > No need to change gitblit’s server side hooks. > > Provide capability to integrate another review tool in future because Gerrit > is loosely coupled with app factory repository creation flow > > Cons > > Implementation is much harder because repository should be manually > synchronized by app factory. Ex: When we create an App, a git repository is > created in Gitblit’s data folder. So app factory should inform gerrit that a > new repository is created. Only then gerrit is aware of that repository. This > notification should be done by app factory. > > There are areas we still haven’t tested. Ex : Forking > > > Considering above facts I selected second approach because > > 1. This does minimal effect to existing app factory flow. > 2. Provide ability to integrate another review tools with minimum changes > > > Events that are needed to handle from app factory side > > <Architecture.png> > > At deployment > > Gerrit’s repository reference is mapped to Gitblit’s repository location. > > At user authentication > > Gerrit can be directly connected to App factory ldap server. > > At tenant creation > > Gerrit has the concept of groups. Currently it can’t handle tenants. We can > reuse this groups concept to implement tenant awareness inside Gerrit > > Eg : > Tenant name : tenant.com > Roles : Admin, Developer, QA, DevOps > > We can create four Gerrit groups to represent above roles and assign > necessary permission to each group (Done through API) > > tenant.com_admin > tenant.com_developer > tenant.com_qa > tenant.com_devops > > > At user creation > > Each user contains in a particular tenant. When a user is created considering > its role, it is added to above groups. (Done through API) > > At App creation > > Normal flow is followed up to repository creation step. > > Once repository creation is done, update Gerrit about the repository via its > APIs. This should be done because Gerrit keeps it’s own database that keeps > metadata of each repository. If we don’t do that Gerrit doesn’t know whether > there is such repository. > > Add groups to newly created repository (tenant.com_admin, > tenant.com_devloper, etc ..) (Done through API) > > Thanks > Dimuthu > > -- > Dimuthu Upeksha > Engineering Intern > WSO2 inc. > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
