Upload
scott-graham
View
799
Download
0
Embed Size (px)
Citation preview
© 2014 IBM CorporationFebruary 22 – 24, 2015
Open Up Your Platform with Open Source & Github!
A Quick Introduction
Agenda
Why Open Source?
Getting Started
Git & Github
General Recommendations
About Me
Scott Graham, IBM WebSphere Team working on Real-Time Communications
The Big Question: Why Open Source?
Why Not?
• Intellectual property concerns
• Licensing Issues
• Internal Bureaucracy
LAWYERS, GUNS AND MONEY
But these can be overcome, and in many cases its worth the effort.
Benefits Take advantage of demand.
Almost every Fortune 500 company today has an Open Source strategy and mandate.
Developer Adoption and Support Increase Adoption of your platform and
tools Get rapid feedback on features Solicit contributions
Community Create a community around your
platform and tools Become part of the Open Source
community in general
Getting Started
An anecdotal story
Everything inside IBM
We moved our client libraries and samples to GitHub to be developer friendly. There are things you can do with Open Source only but by pulling in Liberty you get way more functionality.
First – Pick Something
Samples using your platform APIs
Developer tools
Products that enhance, but are dependent on your platform
Systems Management tools and scripts
Protocol implementations that other people may be interested in adopting
Second – Decide where to put it
GitHubGoogle CodeSourceForgeetc.
And while there are also many others for the remainder of the presentation we will presume you chose GitHub.
Third – Assuming you picked GitHub...
1. Download and install 'git' from git-scm.com
2. Setup 'git' : https://help.github.com/articles/set-up-git/
3. Setup Authentication with GitHub
4. Create a Repository
5. Optional: If you use Eclipse, install EGit
http://eclipse.org/egit/
Git & Github
Some git concepts local and remote[origin]
All changes start local and need to be 'committed' and 'pushed' in order to be persisted remotely(and available to others)
This includes branches.
Branches
Branches “diverge from the main line of development”
They start locally and if you want to share them need to be pushed
Create a branch
git checkout -b branch_name Share the branch with the remote
git push -u origin branch_name
Make some process decisions [hint: git flow]
Branches [the gist]
master – default branch, production ready.
develop – latest develop code, should be stable.
feature/release/defect – used to do work.
Author: Vincent Driessen Original blog post: http://nvie.com/posts/a-succesful-git-branching-model License: Creative Commons BY-SA
Structure your project Projects on GitHub have a common structure
README.mdCONTRIBUTING.mdLICENSE/src/tests/dist
The README.md is automatically served by GitHub when your repository is accessed.
Add install, setup informationHere.
These define how to contribute and the license you are publishing the code under.
Generally stores a distributable version (built) of your app.
Projects in GitHub generally include all of the product's tests and the tests can be run by anyone who clones the project.
Clean it up and push it When moving an existing
project out to the public, ensure you meet your company's licensing requirements.
Remove any internal information (ip addresses, user names, server names) etc.
Add build files and anything else that doesn't belong in source control to your '.gitignore'
# 1. From your project dir, init # as a git repo
$ git init
# 2. Edit .gitignore to ignore files # 3. Add files to be tracked (will# not add files in .gitignore)
$ git add .
# 4. Perform initial commit$ git commit -m 'Initial commit'# 5. Add the remote repository$ git remote add origin rem_repo_url# push it to to remote$ git push origin master
General Recommendations & Issues
Private & Public A GitHub repository can be public or private (if paid) but not
both
In some instances, you may wish to develop code that will support an internal feature of your platform that is not public yet. This is a great scenario for a mixed environment.
Create a Private git repository on GitHub or on an internal server.
Add it to your existing repo.
Create a branch and push it to the private remote.
$ git remote add private [email protected]:[user]/private.repo.git
$ git checkout -b private-branch
$ git push -u private private-branch
Use the GitHub toolsIssues – to track defects/feature requests/etc.
Pull Requests - Handle contributions from others without giving write access to your repository.
Wiki – Document information about your project, the API, etc.
github.io: https://pages.github.com/ – Serve a simple website to advertise and demo your project
Use public package managers If you want people to install and use your code support the
public package managers.
Bower – Client Side JavaScript – http://bower.io
npm – Server Side JavaScripthttp://npmjs.com
Maven – Java Projectshttp://maven.apache.org/
Specific JavaScript considerations Dependencies: To CDN or not to CDN ?
Licensing considerations, performance, version matching
Using Bower?
Provide a CDN for your repo via 'https://rawgit.com/'
Thank You!