Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Development Tools

Development Tools

A lecture given to 2nd year Computing students at the University of Lincoln, covering topics of source control and continuous integration.


Nick Jackson

November 20, 2012



  2. ME! • Nick Jackson • Lead Developer in CERD, formerly

    worked in ICT • nijackson@lincoln.ac.uk • @jacksonj04
  3. TODAY... • Source Control • Continuous Integration

  4. HELPFUL FOR • Group Projects • Software Engineering

  5. SOURCE CONTROL It’s like a time machine for your source

    code. Also, it stops people overwriting your stuff.
  6. SOURCE CONTROL • Also known as “revision control” or “version

    control”. • Key part of Software Configuration Management.
  7. A QUICK HISTORY • Originated with blueprints and legal documents.

    • Return to any previous version. • Visibility of changes. • Improved accountability.
  8. CODE REVISION • Exactly the same. • Return to any

    point in time. • See all changes between any two versions. • See exactly who made which change.
  9. WITH EXTRA GOODNESS • Branching allows different versions to be

    developed side by side, eg development, production and feature. • Tagging specific points in the history, eg previous versions. • Merging different revisions (eg on branches) is possible. • Computers don’t (generally) muck up revisions.
  10. YOU MAY ENCOUNTER... • Microsoft Visual SourceSafe (Discontinued) • CVS

    (Concurrent Versions System) • SVN (Apache Subversion) • GNU Bazaar • Mercurial • Git
  11. TWO FLAVOURS • Centralised. • Distributed.

  12. CENTRALISED • Client-Server model. • Single ‘definitive’ version. • Relies

    on central server. • Eg SourceSafe, CVS, SVN.
  13. DISTRIBUTED • All clients hold complete copy. • No definitive

    version (by default). • More resilient to failure. • Eg Mercurial, Git, Bazaar.
  14. AT LINCOLN • Increasing use of source control in ICT,

    CS, Library. • Majority of teams use Git.
  15. ALL ABOUT GIT • Open source. • Distributed source control.

    • Heavy encouragement of branching and merging.
  16. A QUICK HISTORY OF GIT • Developed by Linux kernel

    developers when they fell out with their proprietary provider. • Wanted distributed, fast source control which stopped corruption of code. • Been developed since 2005.
  17. BRANCHING • Different development paths. • Branch per feature. •

    Branch per developer. • Branch per version.

  19. MERGING • Take changes from one bit of the tree

    (like a branch). • Put them into another bit of the tree.

  21. TAGS • Quickly identify a point in the tree. •

    Specific releases. v1.0
  22. TAGGING D D D F F D D v1.0 v1.1

  23. BRANCHING MODELS • Common set of rules followed by team.

    • We use Git Flow, but others exist. • Clear lines between development, production, bugfixes, features and releases.
  24. Time release branches master develop hot xes feature branches Author:

    Vincent Driessen Original blog post: http://nvie.com/archives/323 License: Creative Commons BY-SA
  25. WHY DO I CARE?

  26. FOR YOURSELF • Rewind time when you totally break things.

    • Try different approaches without altering your working code. • Really easy documentation of changes.
  27. FOR GROUP WORK • All the individual benefits, plus: •

    No more overwriting each others work. • One central ‘definitive’ copy (if you work that way). • Easily break down contributions by person. • Awesome visualisation to see when all your work is done.
  28. ALRIGHT. HOW? • Download Git (it’s free): http://git-scm.com/. • Windows,

    OS X and Linux. • GUIs are available (but command line is more powerful).
  29. GET A REPOSITORY > git init

  30. ADD YOUR FILES > git add .

  31. COMMIT YOUR CHANGES > git commit -a -m ‘First commit.’

  32. DONE.


  34. MAKE A BRANCH > git branch feature_name > git checkout

  35. ON A BRANCH... • Add files (git add) and commit

    (git commit) as normal. • Changes are only made to the specific branch.
  36. MERGING IT BACK TOGETHER • When changes are ready, merge!

    • Compares two points, finds changes, and mixes together. • Usually automatic, may need manual resolution.
  37. MERGING > git checkout master > git merge feature_name

  38. HOW ABOUT FOR GROUPS? • Git is distributed, so no

    central server by default, but; • External repositories are available.
  39. SOME GIT HOSTS • Beanstalk (beanstalkapp.com) • GitHub (github.com) •

    Gitorious (gitorious.org) • Bitbucket (bitbucket.org)
  40. HOSTING CAVEATS • All have a free tier. • Some

    only allow single users in free tier. • Some give unlimited public repos, but not private. • Some don’t have private repos.
  41. WE USE... • GitHub (for most of our Open Source

    stuff) • Bitbucket (for most of our internal stuff)
  42. WHY? • Both have good access control. • Both have

    powerful collaboration tools (issue trackers, wikis). • GitHub has free public repositories for Open Source, so we can involve the community in our work. • Bitbucket has a free academic tier (use lincoln.ac.uk email) which gives us private repositories.
  43. GO TRY • You’ll need a Bitbucket account for the

    workshop. • http://bitbucket.org • It’s totally free. • Use your lincoln.ac.uk email address.
  44. POWER OF REMOTES • Copy of the repository kept somewhere

    else. • Can be anywhere accessible by you. • Common places are network shares and remote servers. • Most common access is using SSH.
  45. ADDING A REMOTE > git remote add origin ssh://git@bitbucket.org/ jacksonj04/helloworld.git

  46. PUSHING AND PULLING • Push moves code from local to

    remote. • Pull does the opposite.
  47. PUSH! > git commit -a -m ‘Awesome changes.’ > git

    push origin master

  49. Kitten Break

  50. CONTINUOUS INTEGRATION Prove that your stuff works with no extra

    effort. Also, you get cool dashboards.

  52. SOURCE CONTROL • Code is neatly managed. • Releases are

    regularly tagged. • A single branch holds your ‘definitive’ code.
  53. DEVELOPMENT BRANCH • Only contains code you think works. •

    Prove it.
  54. UNIT TESTS You all use them, right?

  55. UNIT TESTING • Bunch of tests which ensure your code

    works. • Run manually when you think they’re needed. • May need reconfiguring for test environments. • This takes time.
  56. ENTER CI • Provide automated testing (and other stuff) of

    your code. • Wraps tasks up in a ‘build’. • Runs on a schedule, or on code change. • Not uncommon to run several times a day.
  57. KEY BENEFITS • Clean build environment(s). • No “it won’t

    matter” mentality. • Always have ‘latest build’ ready to go.
  58. A FEW EXAMPLES • Apache Continuum • Bamboo • Buildbot

    • Cruise Control • Jenkins • Travis
  59. WE USE... • Jenkins (jenkins-ci.org) Jenkins

  60. BUT... • We’re not expecting you to use one. •

    Take days to set up and get working properly. • You need to be aware of them (and what they do).
  61. None
  62. LIGHT IT UP • A single ‘go/no-go’ indicator. • Clear

    visual sign of if things are ready to go.
  63. http://www. ickr.com/photos/hanuska/5931613961/in/photostream/

  64. ALL THE FEEDBACK • Continuous Integration gives you loads of

    indicators. • Learn things about your code you didn’t know.
  65. None
  66. ONE OF OURS... • Gets code from repository. • Runs

    a series of tests. • Compiles scripts. • Compresses content. • Performs analysis to find which files to deploy. • Deploys to server. • Cleans up after itself.

  68. BEGINNING TO END • Write code. • Check in to

    repository. • Continuous Integration runs. • Working application, or error report.
  69. DONE.