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

More Decks by Nick Jackson

Other Decks in Technology



  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.