I'm the founder of https://organice.io, a collaboration platform based on Django technology, and co-founder of https://painless.software, a best-practice consultancy in software development. All presentation material is governed by CC BY-SA 4.0
for TYPO3 Developers
TYPO3camp Stuttgart 2017
live slides @ tinyurl.com/t3c-cd
8 Developers, 1 ScrumMaster, 1 Coach
2 PM, 1 Accountant
1 office, 1 terrace, 1 grill, 1 soccer table
plenty of chocolate
- (C-level management) hype
- Replacement for Scrum+Kanban?
- 1st principle of Agile Manifesto
- All automatic, just push code!
- TDD, BDD, Selenium, Docker
- Deployment button for business
What Is It?
... a set of practices and principles ...
building, testing, and releasing software,faster and more frequently
... put release schedule in the hands of
the business - not IT
It's Agile (Ever Since)
Satisfy the customer!
TDD, BDD, Selenium
Tests are fundamental for build pipeline.
- No automated verification w/o tests
- No safeguarding against regression
- No safety net against deployments
that would take the site down
TDD good practice
BDD helpful for acceptance
Selenium / performance
!! risk !!
Containers make process easier.
- Feature parity across environments
- Develop, Staging, Production identical
- Simplify deployments, no builds on hosts
- Simplify rollbacks
Optional, but makes it easier
Container images built by pipeline
Push complete system
- On-boarding developers takes days
- "Works on my machine"
- Not releasing enough features
- Only a few can trigger deployment
- "Never deploy on a Friday!"
- Move to a different hoster (cloud?)
Does It Solve My Problems?
The Definition Said
- Build features faster + more frequently
- Test changes faster + more frequently
- Release changes faster + more frequently
- Everyone (even the client) can release
... and Docker said
- Environment parity (production = staging = dev machine)
That's the Plan
So, in future, we will:
- Clone a repo + run a project locally
- Make, test + push changes
- Get feedback from build server
- Have changes reviewed + released
All in a matter of minutes
No fear to break anything
Happy devs + clients
- Version control
- Feature branching - maybe
- Code review, PRs / MRs
- A test runner, task runner
- Build server, CI server, pipeline
- Artifact storage, image registry
What Do We Need?
Someone needs to ship it.
What to Look at
Someone needs to maintain it.
- Infrastructure as code
- Agent-less deployment
- Stick to standard procedures +
popular tools (best practices)
- Make it work for everyone
Don't break conventions
Make developers love it!
Build Servers + Registries
Someone needs to build it.
- Pipeline will build, push and deploy
- Pick a solution or combo you love to work with (GitHub+Travis+DockerHub, GitLab, ...)
- Hosted may be cheaper than self-hosted (TCO)
- Build speed, pleasant UI + workflow may
pay off more than a smaller price
CI Services: http://alternativeto.net/software/travis-ci/
Someone needs to serve it.
- Decent Docker hosting supports `docker machine` drivers
- Regular (dedicated) hosting with `docker` and `docker-compose` also works
- Avoid manual setup (transient servers)
Someone needs to babysit it.
- Screen resource utilization after deployment
- Some issues are only discovered in production
- Capture stack traces, identify bottlenecks
- Get user feedback, communicate w/ users
- Collect historical data
- php-cs-fixer, sass-lint, jshint
- phpunit, typo3_console
- GitHub+Travis CI / GitLab / Bitbucket
Run project: `docker-compose up`
Clear cache from command line
Run tests: `phpunit` or ???
Don't Create Config Files!
- Create a project skeleton (cookiecutter)
- Use existing cookiecutters
- Contribute to the one you love best!
- Do the hard stuff in public (it will pay off)
Then start working immediately!
Continuous Delivery for TYPO3 Developers - TYPO3camp Stuttgart
By Peter Bittner