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.

C7f3b4756d808ef0e2548bd0965ac225?s=128

Nick Jackson

November 20, 2012
Tweet

Transcript

  1. 2.

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

    worked in ICT • nijackson@lincoln.ac.uk • @jacksonj04
  2. 5.

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

    code. Also, it stops people overwriting your stuff.
  3. 6.

    SOURCE CONTROL • Also known as “revision control” or “version

    control”. • Key part of Software Configuration Management.
  4. 7.

    A QUICK HISTORY • Originated with blueprints and legal documents.

    • Return to any previous version. • Visibility of changes. • Improved accountability.
  5. 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.
  6. 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.
  7. 10.

    YOU MAY ENCOUNTER... • Microsoft Visual SourceSafe (Discontinued) • CVS

    (Concurrent Versions System) • SVN (Apache Subversion) • GNU Bazaar • Mercurial • Git
  8. 13.

    DISTRIBUTED • All clients hold complete copy. • No definitive

    version (by default). • More resilient to failure. • Eg Mercurial, Git, Bazaar.
  9. 14.

    AT LINCOLN • Increasing use of source control in ICT,

    CS, Library. • Majority of teams use Git.
  10. 15.

    ALL ABOUT GIT • Open source. • Distributed source control.

    • Heavy encouragement of branching and merging.
  11. 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.
  12. 17.

    BRANCHING • Different development paths. • Branch per feature. •

    Branch per developer. • Branch per version.
  13. 19.

    MERGING • Take changes from one bit of the tree

    (like a branch). • Put them into another bit of the tree.
  14. 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.
  15. 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
  16. 26.

    FOR YOURSELF • Rewind time when you totally break things.

    • Try different approaches without altering your working code. • Really easy documentation of changes.
  17. 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.
  18. 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).
  19. 32.
  20. 35.

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

    (git commit) as normal. • Changes are only made to the specific branch.
  21. 36.

    MERGING IT BACK TOGETHER • When changes are ready, merge!

    • Compares two points, finds changes, and mixes together. • Usually automatic, may need manual resolution.
  22. 38.

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

    central server by default, but; • External repositories are available.
  23. 39.

    SOME GIT HOSTS • Beanstalk (beanstalkapp.com) • GitHub (github.com) •

    Gitorious (gitorious.org) • Bitbucket (bitbucket.org)
  24. 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.
  25. 41.

    WE USE... • GitHub (for most of our Open Source

    stuff) • Bitbucket (for most of our internal stuff)
  26. 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.
  27. 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.
  28. 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.
  29. 46.

    PUSHING AND PULLING • Push moves code from local to

    remote. • Pull does the opposite.
  30. 50.
  31. 52.

    SOURCE CONTROL • Code is neatly managed. • Releases are

    regularly tagged. • A single branch holds your ‘definitive’ code.
  32. 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.
  33. 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.
  34. 57.

    KEY BENEFITS • Clean build environment(s). • No “it won’t

    matter” mentality. • Always have ‘latest build’ ready to go.
  35. 58.

    A FEW EXAMPLES • Apache Continuum • Bamboo • Buildbot

    • Cruise Control • Jenkins • Travis
  36. 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).
  37. 61.
  38. 62.

    LIGHT IT UP • A single ‘go/no-go’ indicator. • Clear

    visual sign of if things are ready to go.
  39. 64.

    ALL THE FEEDBACK • Continuous Integration gives you loads of

    indicators. • Learn things about your code you didn’t know.
  40. 65.
  41. 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.
  42. 68.

    BEGINNING TO END • Write code. • Check in to

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