Development Tools

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

Transcript

1. DEVELOPMENT TOOLS
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.
18. F D D F D BRANCHING D
19. MERGING • Take changes from one bit of the tree (like a branch). • Put them into another bit of the tree.
20. D MERGING D D D F F D
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.
33. BRANCHING?
34. MAKE A BRANCH > git branch feature_name > git checkout feature_name
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
48. QUESTIONS?
49. Kitten Break
50. CONTINUOUS INTEGRATION Prove that your stuff works with no extra effort. Also, you get cool dashboards.
51. CAUTION: THEORY AHEAD
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).
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.
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.
67. QUESTIONS?
68. BEGINNING TO END • Write code. • Check in to repository. • Continuous Integration runs. • Working application, or error report.
69. DONE.
70. WORKSHOP TODAY, 2PM, LABS