4. What Is Jenkins?
● You can let Jenkins type for you the way you
want it to be
5. Git+Jenkins
● Just like SVN+Jenkins
● Authentication
– Public key: /home/user/.ssh/id_rsa.pub
– Private key: /home/user.ssh/id_rsa
6. Git from developer PoV
● Get the working copy
git clone git@github.com:twitter/bootstrap.git
git clone https://github.com/twitter/bootstrap.git
git clone git://github.com/twitter/bootstrap.git
● Select branch
git checkout master
● Create a new working branch
git checkout -b PRODUCTBACKLOG-2000 master
git checkout -b <NEW_BRANCH> <REFERENCE_BRANCH>
git checkout -b <NEW_BRANCH> #default is current branch
7. Git from developer PoV
● Commit changes
git commit
git commit -m
git commit -a -s
● Rebase
“Put your local changes as the latest changes from
the rebasee branch on your local working copy”
8. Rebase
● Put your local changes as the latest changes
of the universe.
– You have the latest status of the collaboration
branch.
– Your change is just an addition, won't conflict to
others'.
– Safer than merge
– http://mislav.uniqpath.com/2013/02/merge-vs-
rebase/
10. Git from Jenkins PoV
● Our Jenkins deploys from feature branch, NOT
from integration branch
● Not from master
● Not from origin/master
● Why? We need it
● We don't maintain build history since the
branch is inconsistent in every build
11. Git from Jenkins PoV
● Build is parameterized
– Branch's name
– Target server
● Always checkout a new copy
● git checkout -b b-XyZ-PRODUCTBACKLOG-2000 origin/PRODUCTBACKLOG-2000
● Build
● Deploy to target server
12. Rex
● An instrument to build and deploy
● We have several groups of servers
– They have different purpose
– Different version of code
– Different user
● http://rexify.org
● deploy/Rexfile
13. How To Rex?
● rex -T
● rex -E integration do_deploy –target=platform
● rex -E staging do_deploy –target=th
● Relax, it's all done by Jenkins.
