Continuous Delivery
for TYPO3 Developers

TYPO3camp Stuttgart 2017

live slides @ tinyurl.com/t3c-cd

comsolit AG

8 Developers, 1 ScrumMaster, 1 Coach

2 PM, 1 Accountant

www.comsolit.com

Peter Bittner

info@comsolit.com

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?

   .

Definition

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

Text

Source: https://painless.software/continuous-delivery

It's Agile (Ever Since)

Source: http://agilemanifesto.org/principles.html

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

Containers (Docker)

Containers make process easier.

• Feature parity across environments
• Develop, Staging, Production identical
• Simplify deployments, no builds on hosts
• Simplify rollbacks

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

Definition: https://painless.software/continuous-delivery

That's the Plan

So, in future, we will:

1. Clone a repo + run a project locally
2. Make, test + push changes
3. Get feedback from build server
4. Have changes reviewed + released

• Version control
• Feature branching - maybe
• Code review, PRs / MRs
• A test runner, task runner
• Build server, CI server, pipeline
• Artifact storage, image registry
• Hosting
• Monitoring

What Do We Need?

Development Process

Someone needs to ship it.

push code

open PR/MR

approve

build

review

feature

production

system

branch

server

system

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

*

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/

Registries: http://alternativeto.net/software/docker-hub/

Docker Hosting

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)

Shortlist: https://blog.codeship.com/the-shortlist-of-docker-hosting/

Monitoring

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

Monitoring: http://alternativeto.net/software/sentry/

Transparency: https://painless.software/transparency

TYPO3 Choices

• composer
• php-cs-fixer, sass-lint, jshint
• phpunit, typo3_console
• GitHub+Travis CI / GitLab / Bitbucket

Don't Create Config Files!

1. Create a project skeleton (cookiecutter)
2. Use existing cookiecutters
3. Contribute to the one you love best!
4. Do the hard stuff in public (it will pay off)