Design and Evolution of cyber-dojo
summary
cyber-dojo migrates from a Ruby monolith to separate services and a Travis-driven build chain where each repo builds a Docker image, runs its tests inside that image, and pushes to Docker Hub. the key bug is inconsistent dependent images; the chosen fix is git-hash tagging plus a final system-test step that promotes a consistent set of images. testing includes a tiny HTTP client for dual client-server testing, running the same specs on Alpine and Ubuntu, a Ruby mini-framework with hex test IDs, and a policy of 100% coverage.
AI-written summary · about
chapters (12)
- 0:00Start
- 5:06build architecture?
- 6:48client-server testing
- 7:26100% coverage
- 8:14pro: refactoring
- 8:38pro: reveals poor design
- 9:39Q: what does this tell us?
- 9:50A: different levels of abstraction
- 10:06pro: design pressure
- 10:20pro: deleting dead code
- 11:26custom ruby testing-framework
- 15:05monitoring
related talks
40mDeveloping Ruby Applications with Docker
01h 04mDevOps, Waffles, and Superheroes. Oh my!
49mRuby Software Continuously Delivered and Exhaustively Explained
49mThe road to continuous deployment: a case study
01h 01mShipping Ruby Apps with Docker
41mEverything Ruby
42mUse Docker to test microservices
25mRuby in containers