In a continuous delivery environment web application updates are pushed out fast and frequently. Implementing that environment requires many different pieces: version control, automated testing, and automated deployment. It’s a lot to wrap your head around, but there are tangible benefits for small schools, including new opportunities to collaborate among institutions or with student developers. In this presentation we will demonstrate how to build a lightweight continuous integration and delivery stack using free and open source tools: GitLab for version control, GitLab CI and Docker for testing, and Docker and Capistrano for deployment. We will walk through how each piece is separately important and how combining them creates a simple yet powerful deployment strategy. We will also describe concrete examples of how we are using these tools to share application development with students and each other.

1. Lightweight continuous delivery
for small schools
Charles Fulton (Lafayette College)
Kevin Wiliarty (Hampshire College)
#ne12

2. ...or, “Script and version all the things!”

3. Who we are
● Charles Fulton (@mackensen), Senior Web Applications Developer, Lafayette
College
● Kevin Wiliarty, Senior Web Programmer, Hampshire College

4. What we’re doing here
● A free and open source self-hosted continuous delivery stack
● We’re going to give you all the nouns
● Yes, all of them

5. Continuous delivery
Continuous Delivery is a software development discipline where you build software in
such a way that the software can be released to production at any time.
You achieve continuous delivery by continuously integrating the software done by the
development team, building executables, and running automated tests on those
executables to detect problems.
-- Martin Fowler
http://martinfowler.com/bliki/ContinuousDelivery.html

6. Challenges
Version control
Collaboration
Quality assurance
Integration
Delivery
Solutions
Git
GitLab
Behat
Docker
Capistrano

7. Version control

8. Benefits of using git
http://guides.beanstalkapp.com/version-control/intro-to-version-control.html
● It helps you master complexity
● It permits you to disperse development
● It’s both free and open source
● It’s inevitable

9. Complexity
http://gource.io/
● Track changes, but for an entire project
● Visualize the progression of your project over time
● Maintain versioned branches
● Manage local customizations
● Have the confidence to make major changes

10. Dispersal
● No “central” repository with git
● Cheap branching and merging
● Concurrent development across teams
Publish
WorkDev #1
Dev #2
http://marklodato.github.io/visual-git-guide/index-en.html

11. Free and open source
● No artificial limitations
● Total ownership of the tools and the resulting product
http://choosealicense.com/

12. Inevitability
“In 2010, SVN was still the top version control system, used in 60% of software projects,
while Git was used in just 11%. But today, Git has nearly matched SVN’s market share.”
-- Nadia Eghbal
https://medium.com/@nayafia/we-re-in-a-brave-new-post-open-source-world-56ef46d152a3

13. Collaboration

14. Social coding: Github
● Store
● Distribute
● Expose
● Report
● Follow
● Document
● Visualize
● Test
● Fork
● Contribute

15. Fork and Contribute

16. Institutional coding: GitLab
● Identity management
● Institutional continuity
● Audience control
● Price
● Openness and freedom
https://about.gitlab.com/

17. Quality assurance

18. Testing your assumptions
● Manual testing is time-intensive and boring every time you do it
● Automated testing is time-intensive and boring once, and then never again
● Manual testing makes you hesitant to make major changes
● Automated testing gives you the confidence to destroy everything at once
https://docs.moodle.org/dev/Testing

19. Behat
● Automated
● Behavior-driven
● User stories
http://docs.behat.org/en/v3.0/

20. Storytelling
http://iansommerville.com/systems-software-and-technology/giving-up-on-test-first-development/

21. Telling your code a
story before bed

22. Look, Ma, no hands!
http://www.seleniumhq.org/

23. Look, Ma, no head!
http://tenon.io/
● Computers don't need to look at a
browser
● Headless testing can expose
accessibility issues

24. Integration

25. Continuous integration, continuously
● Establish a sane process
● Test every commit
● Stay out of the gears

26. Look, Ma, no nothin'!

27. Containers: Docker
● Software containers
● Scriptable
● Available on demand
● Disposable
● Repeatable
https://medium.freecodecamp.com/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b

28. .gitlab-ci.yml
● GitLab launches Docker containers
● Installs latest version of project
● Runs your tests
● Reports your results
https://about.gitlab.com/gitlab-ci/

29. Test results

30. Fork, Test, Contribute, Test

31. Delivery

32. Last-mile problem
● All this talk of projects, it’s exhausting
● How do I make my project useful?
● Manual solution: climb pole maintain clone of
repository on production server

33. Downsides to climbing utility pole
● Introduces scope for error
● Requires “physical” access to the server
● Maintains the full history of the project on the server

34. A pipeline, not a utility pole
1. Commit your change
2. Tests pass
3. ???
4. Profit!

35. Capistrano
● Ruby application
● Manages the deployed state of your project, in addition to code
● Deployments can be executed locally, or from another system
http://capistranorb.com/

36. Extended metaphor about the American cliff swallow
● Swallows always return to Capistrano...something something...delivery!
● Swallows may or may not take trains to Capistrano.

37. Capistrano in a container
● Provision one more docker container with ruby and SSH
● Add a job to .gitlab-ci.yml to run the deploy task in a ruby container
http://sites.lafayette.edu/fultonc/2015/11/12/quick-note-on-agent-forwarding-with-docker/

38. Script and version all the things!
● Everything is in git and attached to your project:
○ Code changes
○ Acceptance tests
○ Testing environment configuration
○ Deployment configuration

39. Building your pipeline
1. Commit my changes in git
2. Push them to GitLab
3. GitLab spins up a Docker container to run QA tests
4. The tests pass
5. GitLab spins up another Docker container to deploy the project
6. Profit!

40. Questions?

41. Image credits
● Git logo by Jason Long [CC BY 3.0], via Wikimedia Commons
● GitHub logo https://github.com/logos
● GitHub octocat https://github.com/logos
● GitLab wordmark https://about.gitlab.com/press/
● Docker logo https://www.docker.com/brand-guidelines
● User icon (modified) by WMF User Experience Design Group [MIT License], via
Wikimedia Commons
● Man on telephone pole by Unknown or not provided (U.S. National Archives and
Records Administration) [Public domain], via Wikimedia Commons
● Second Los Angeles Aqueduct Cascades, Sylmar by Los Angeles [CC BY-SA 3.0]
via Wikimedia Commons
● Cliff swallow in flight by Don DeBold, [CC BY 2.0], via Flickr