Development Tools - Speaker Deck

Slide 1

Slide 1 text

DEVELOPMENT TOOLS

Slide 2

Slide 2 text

ME! • Nick Jackson • Lead Developer in CERD, formerly worked in ICT • [email protected] • @jacksonj04

Slide 3

Slide 3 text

TODAY... • Source Control • Continuous Integration

Slide 4

Slide 4 text

HELPFUL FOR • Group Projects • Software Engineering

Slide 5

Slide 5 text

SOURCE CONTROL It’s like a time machine for your source code. Also, it stops people overwriting your stuff.

Slide 6

Slide 6 text

SOURCE CONTROL • Also known as “revision control” or “version control”. • Key part of Software Conﬁguration Management.

Slide 7

Slide 7 text

A QUICK HISTORY • Originated with blueprints and legal documents. • Return to any previous version. • Visibility of changes. • Improved accountability.

Slide 8

Slide 8 text

CODE REVISION • Exactly the same. • Return to any point in time. • See all changes between any two versions. • See exactly who made which change.

Slide 9

Slide 9 text

WITH EXTRA GOODNESS • Branching allows different versions to be developed side by side, eg development, production and feature. • Tagging speciﬁc points in the history, eg previous versions. • Merging different revisions (eg on branches) is possible. • Computers don’t (generally) muck up revisions.

Slide 10

Slide 10 text

YOU MAY ENCOUNTER... • Microsoft Visual SourceSafe (Discontinued) • CVS (Concurrent Versions System) • SVN (Apache Subversion) • GNU Bazaar • Mercurial • Git

Slide 11

Slide 11 text

TWO FLAVOURS • Centralised. • Distributed.

Slide 12

Slide 12 text

CENTRALISED • Client-Server model. • Single ‘deﬁnitive’ version. • Relies on central server. • Eg SourceSafe, CVS, SVN.

Slide 13

Slide 13 text

DISTRIBUTED • All clients hold complete copy. • No deﬁnitive version (by default). • More resilient to failure. • Eg Mercurial, Git, Bazaar.

Slide 14

Slide 14 text

AT LINCOLN • Increasing use of source control in ICT, CS, Library. • Majority of teams use Git.

Slide 15

Slide 15 text

ALL ABOUT GIT • Open source. • Distributed source control. • Heavy encouragement of branching and merging.

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

F D D F D BRANCHING D

Slide 19

Slide 19 text

MERGING • Take changes from one bit of the tree (like a branch). • Put them into another bit of the tree.

Slide 20

Slide 20 text

D MERGING D D D F F D

Slide 21

Slide 21 text

TAGS • Quickly identify a point in the tree. • Speciﬁc releases. v1.0

Slide 22

Slide 22 text

TAGGING D D D F F D D v1.0 v1.1

Slide 23

Slide 23 text

BRANCHING MODELS • Common set of rules followed by team. • We use Git Flow, but others exist. • Clear lines between development, production, bugﬁxes, features and releases.

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

WHY DO I CARE?

Slide 26

Slide 26 text

FOR YOURSELF • Rewind time when you totally break things. • Try different approaches without altering your working code. • Really easy documentation of changes.

Slide 27

Slide 27 text

FOR GROUP WORK • All the individual beneﬁts, plus: • No more overwriting each others work. • One central ‘deﬁnitive’ copy (if you work that way). • Easily break down contributions by person. • Awesome visualisation to see when all your work is done.

Slide 28

Slide 28 text

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).

Slide 29

Slide 29 text

GET A REPOSITORY > git init

Slide 30

Slide 30 text

ADD YOUR FILES > git add .

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

DONE.

Slide 33

Slide 33 text

BRANCHING?

Slide 34

Slide 34 text

MAKE A BRANCH > git branch feature_name > git checkout feature_name

Slide 35

Slide 35 text

ON A BRANCH... • Add ﬁles (git add) and commit (git commit) as normal. • Changes are only made to the speciﬁc branch.

Slide 36

Slide 36 text

MERGING IT BACK TOGETHER • When changes are ready, merge! • Compares two points, ﬁnds changes, and mixes together. • Usually automatic, may need manual resolution.

Slide 37

Slide 37 text

MERGING > git checkout master > git merge feature_name

Slide 38

Slide 38 text

HOW ABOUT FOR GROUPS? • Git is distributed, so no central server by default, but; • External repositories are available.

Slide 39

Slide 39 text

SOME GIT HOSTS • Beanstalk (beanstalkapp.com) • GitHub (github.com) • Gitorious (gitorious.org) • Bitbucket (bitbucket.org)

Slide 40

Slide 40 text

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.

Slide 41

Slide 41 text

WE USE... • GitHub (for most of our Open Source stuff) • Bitbucket (for most of our internal stuff)

Slide 42

Slide 42 text

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.

Slide 43

Slide 43 text

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.

Slide 44

Slide 44 text

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.

Slide 45

Slide 45 text

ADDING A REMOTE > git remote add origin ssh://[email protected]/ jacksonj04/helloworld.git

Slide 46

Slide 46 text

PUSHING AND PULLING • Push moves code from local to remote. • Pull does the opposite.

Slide 47

Slide 47 text

PUSH! > git commit -a -m ‘Awesome changes.’ > git push origin master

Slide 48

Slide 48 text

QUESTIONS?

Slide 49

Slide 49 text

Kitten Break

Slide 50

Slide 50 text

CONTINUOUS INTEGRATION Prove that your stuff works with no extra effort. Also, you get cool dashboards.

Slide 51

Slide 51 text

CAUTION: THEORY AHEAD

Slide 52

Slide 52 text

SOURCE CONTROL • Code is neatly managed. • Releases are regularly tagged. • A single branch holds your ‘deﬁnitive’ code.

Slide 53

Slide 53 text

DEVELOPMENT BRANCH • Only contains code you think works. • Prove it.

Slide 54

Slide 54 text

UNIT TESTS You all use them, right?

Slide 55

Slide 55 text

UNIT TESTING • Bunch of tests which ensure your code works. • Run manually when you think they’re needed. • May need reconﬁguring for test environments. • This takes time.

Slide 56

Slide 56 text

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.

Slide 57

Slide 57 text

KEY BENEFITS • Clean build environment(s). • No “it won’t matter” mentality. • Always have ‘latest build’ ready to go.

Slide 58

Slide 58 text

A FEW EXAMPLES • Apache Continuum • Bamboo • Buildbot • Cruise Control • Jenkins • Travis

Slide 59

Slide 59 text

WE USE... • Jenkins (jenkins-ci.org) Jenkins

Slide 60

Slide 60 text

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).

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

LIGHT IT UP • A single ‘go/no-go’ indicator. • Clear visual sign of if things are ready to go.

Slide 63

Slide 63 text

http://www. ickr.com/photos/hanuska/5931613961/in/photostream/

Slide 64

Slide 64 text

ALL THE FEEDBACK • Continuous Integration gives you loads of indicators. • Learn things about your code you didn’t know.

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

ONE OF OURS... • Gets code from repository. • Runs a series of tests. • Compiles scripts. • Compresses content. • Performs analysis to ﬁnd which ﬁles to deploy. • Deploys to server. • Cleans up after itself.

Slide 67

Slide 67 text

QUESTIONS?

Slide 68

Slide 68 text

BEGINNING TO END • Write code. • Check in to repository. • Continuous Integration runs. • Working application, or error report.