Hi Luca,
On Wed, Feb 12, 2014 at 2:32 AM, Luca Milanesio <[email protected]>wrote: > Would it be a public review of the changes ? Team member vs non team > member does not seems an objective validation of the code quality. > > Changes should be merged because they make sense and not based on the > email domain ownership IMHO. > Ofcause that will always be the case if an internal team member produce bad code it wont be merged. Actaully within WSO2 internal developers will not get commitership until they prove themselves with quality code and best practices. We regularly have code reviews, and with git migration we can comment on the code publicly and if its good only we will merge. Regards, /Nuwan > > Luca > > On 12 Feb 2014, at 03:40, Afkham Azeez <[email protected]> wrote: > > > > > On Wed, Feb 12, 2014 at 8:47 AM, Shevan Goonetilleke <[email protected]>wrote: > >> Hi Sagara, >> >> The pull request sent from a non-team member will have to be merged >> manually by the respective team right? The automated validate and merge >> will be only at the company level? >> > > Any pull requests to the team repos have to be manually merged. > > >> >> Thanks >> Shevan >> >> >> On Tue, Feb 11, 2014 at 11:31 PM, Sagara Gunathunga <[email protected]>wrote: >> >>> >>> Please find proposed Validate & Merge architecture for platform projects >>> based on a POC we did during last few days. Once we implemented, this will >>> be a huge step to reach continuous delivery mode. >>> >>> <repo.png> >>> >>> >>> Example workflow is given below based on "carbon-deployment" project own >>> by AS team. >>> >>> >>> - In WSO2 organisation level there will be a GitHub repo[1], Jenkins >>> build server and Nexus server available and those are common for all >>> projects and own by Infra/Admin team. >>> >>> - There will be a build VM given for each team and they can run their >>> own Jenkins server. >>> >>> - There will be a "GIT Proxy" available on organisation level Jenkins >>> server that can accept pull request in behalf of organisation level GitHub >>> repo[1] >>> >>> >>> >>> >>> 1.) Responsible person from AS team fork "carbon-deployment" project >>> from WSO2 repo [1] to team level repo [2] ( This is a one time task). >>> >>> 2.) Each team member clone team level GIT repo[2] locally. >>> >>> 3.) Each team member modify code and frequently commit to their local >>> cloned repo. >>> >>> 4.) When a feature reach do Done-Done state team member can push to AS >>> team level repo. >>> >>> 5.) Team level Jenkins server automatically trigger a build based on SCM >>> change just happened and team can validate the change based on build >>> results. ( In addition to carbon-deployment job team may create Jenkins >>> jobs for downstream projects to validate the change further ) >>> >>> 6.) When the team wish to merge above feature to organisational level >>> repo, a responsible person from the team can send a GIT pull request from >>> Team repo[2] to GIT proxy available on organisation level Jenkins. >>> >>> 7.) "GIT Proxy" accept pull requests from team level repo and trigger a >>> Jenkins build with the changes received from current pull request. >>> >>> 8.) Eventually Jenkins builds all downstream projects and validate pull >>> request. >>> >>> 9.) If any downstream projects build fail then discard the pull request >>> and notify authors of pull request/commit about the failure. >>> >>> 10.) If all downstream projects build succeed Jenkins will automatically >>> >>> a.) Merge pull request to organisation level GitHub repo[1] >>> >>> b.) Deploy built artefacts in to Nexus snapshot repo >>> >>> >>> >>> NOTE - When it come to NON team member contribution, only change is >>> during the step-4 he can't push to team repo directly instead he will send >>> a pull request to Team level repo [1]. >>> >>> >>> Right now we are evaluating number of solutions to implement "GIT >>> Proxy" component and there is a high chance that we will end up writing a >>> Jenkins plugin to cater this requirement. In future this plug-in/solution >>> can be used with AF to cater similar requirements. >>> >>> [1] - https://github.com/wso2/carbon-deployment >>> [2] - https://github.com/wso2as-developer/carbon-deployment >>> >>> >>> Thanks ! >>> >>> >>> -- >>> Sagara Gunathunga >>> >>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>> V.P Apache Web Services; http://ws.apache.org/ >>> Linkedin; http://www.linkedin.com/in/ssagara >>> Blog ; http://ssagara.blogspot.com >>> >>> >> >> >> -- >> Shevan Goonetilleke >> Director of Engineering >> WSO2, Inc. >> lean.enterprise.middleware >> m: +94777340680 >> w: http://wso2.com >> > > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> > * linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > > _______________________________________________ > 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 > > -- *Thanks & Regards,Nuwan BandaraTechnical Lead; **WSO2 Inc. * *lean . enterprise . middleware | http://wso2.com <http://wso2.com> * *blog : http://nuwanbando.com <http://nuwanbando.com>; email: [email protected] <[email protected]>; phone: +1 812 606 7390 * <http://www.nuwanbando.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
