The document discusses a Ruby workflow that focuses on continuous integration and deployment. It is presented by Clemens Helm, a Codeship employee, and proposes a workflow involving developing on feature branches, creating pull requests to merge code to the master branch, and then automatically deploying to production after the code is merged. The workflow aims to get ideas to users quickly through short development cycles, encourage contributions, and ensure code quality while making deployments effortless. However, it notes that the pull request cycle can be a potential downside.

1. The Ruby workflow
or: Less workflow, more Ruby.

2. Who am I?
Clemens Helm @clemenshelm
• Codeship mate
• Web & Rails
• Screencaster
• Vienna office

3. Why am I talking?
• Proposal @ Euruko
• Works great @ Codeship
• 10 deploys per (good) day

4. The workflow
1. Develop
2. Pull request
3. Go live

5. Develop
• Git feature branches
• Tiny features
• Behavior-driven development
• Continuous Integration

6. Continuous Integration
Tests on every push to GitHub

7. Pull request
Request merge into master branch

8. Ooops…

9. Continuous Deployment
Implicitly after merge.

10. Continuous Deployment

11. Continuous Deployment
Test%
Deployment%

12. (Dis)advantages
+ Only hours from idea to shipping it
+ Everybody can contribute
+ Code quality
+ Shared knowledge
+ Deployment just happens
– Pull request cycle

13. Your 2 cents.