GIT 101 @ WSO2

Git

Git is yet another source code management like SVN, Harvard, Mercurial and So on!

Why GIT?

Why GIT instant of SVN in wso2?

I do not know why! it might be a off site meeting decision taken in the trinco after landing with adventurous flight trip ;)

• awesome support for automation story
• Easy to manage
• No need to worry about backup and other infrastructure issues.
• User friendly
• Publicly your code reputation is available.

GIT in WSO2.

WSO2 has two different repository.

• Main Repository.
• Main purpose of this repository maintain the unbreakable code repository and actively build for the continuous delivery story incomprated with integrated automation.
• https://github.com/wso2
• Development Repository.
• Development repository is the place teams play around with their active development.
• https://github.com/wso2-dev
• wso2-dev is a fork of wso2 repo!

UPDATE

Now this statement invalid as WSO2 has changed it process on Dec/2014

Rules

1. Developer should not fork wso2 repo.
1. Technically he/she can but the pull request will not accepted.
2. If something happen and build breaks! He/She should take the entire responsible and fix the issue and answer the mail thread following the build break :D
2. Developer should fork respective wso2-dev repo.
1. He/She can work on the development on her/his forked repo and when he/she feel build won't break he/she need to send the pull request to wso2-dev.
2. If pull request should be reviewed by respective repo owners and merge.
3. On the merge, Integration TG builder machine will get triggered and if build pass no problem. If fails, He/She will get a nice e-mail from Jenkins ;) so do not spam or filter it :D. Quickly respective person should take the action to solve it.
3. When wso2-dev repository in a stable condition, Team lead/Release manager/ Responsible person  has to send a pull request from wso2-dev to wso2.
1. WSO2 has pre-builder machine to verify the pull request is valid or not.
1. if build is passed and the person who send a pull request is white listed the pull request will get merged in the main repository.
2. if build fails, the pull request will be terminated and mail will send to the respective person who send the pull request. So now, respective team has to work out and fix the issue.
3. Build pass but not in whitelist prebuild mark it a need to reviewed by admin. But ideally admin will close that ticket and ask the person to send the pull request to wso2-dev ;)
4. If everyting merged peacefully in main repo. Main builder machine aka continuous delivery machine  build it. If it is fail, TEAM need to get into action and fix it.
4. You do not need to build anything in upstream, ideally everything you need should fetched from the Nexus.
5. Allways sync with the forked repository

GIT Basics

1. Fork the respective code base to your git account
2. git clone github.com/wso2-dev/abc.git
3. git commit -m “blha blah blah”
4. git commit -m “Find my code if you can” -a
5. git add myAwsomeCode.java
6. git push

Git Beyond the Basics

• Sych with upstream allways before push the code to your own repository

WSO2 GIT with ESB team

ESB team owns

1. https://github.com/wso2-dev/wso2-synapse
2. https://github.com/wso2-dev/carbon-mediation
3. https://github.com/wso2-dev/product-esb/

Nobody else other than in ESB team has the mergeship :P for these code repository. So whenever somebody try to screw our repo, please take a careful look before merge!

The first principle is no one suppose to build anything other than currently working project.

Good to read

http://www.vogella.com/tutorials/Git/article.html

[Architecture] Validate & Merge solution for platform projects

Maven Rules in WSO2

Please find POM restructuring guidelines in addition to things we discussed during today's meeting.  

1. Top level POM file is the 'parent POM' for your project and there is no real requirement to have separate Maven module to host parent POM file.
2. Eliminate POM files available on 'component' , 'service-stub' and 'features' directories as there is no gain from them instead directly call real Maven modules from parent pom file ( REF - [1] )
3. You must have a    section on parent POM and should define all your project dependencies along with versions.
4. You CAN'T have  sections on any other POM file other than parent POM.
5. In each submodule make sure you have Maven dependencies WITHOUT versions.
6. When you introduce a new Maven dependency define it's version under section of parent POM file.  
7. Make sure you have defined following repositories and plugin repositories on parent POM file. These will be used to drag SNAPSHOT versions of other carbon projects which used as dependencies of your project.