Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Continuous Delivery for TYPO3 Developers - TYPO3camp Stuttgart

Continuous Delivery for TYPO3 Developers - TYPO3camp Stuttgart

Continuous Delivery sounds easy in theory, but it’s hard to do in practice. There are myriads of things you can and should do to get your code delivered faster, reliably. We look at what we can do as TYPO3 developers, or as a small or mid-sized team to make the industrialized software development production chain come true.

See the original presentation at http://slides.com/bittner/typo3camp-stuttgart-continuous-delivery

Peter Bittner

May 13, 2017
Tweet

More Decks by Peter Bittner

Other Decks in Technology

Transcript

  1. comsolit AG 8 Developers, 1 ScrumMaster, 1 Coach 2 PM,

    1 Accountant www.comsolit.com Peter Bittner [email protected] 1 office, 1 terrace, 1 grill, 1 soccer table plenty of chocolate
  2. Cool Stuff? We'll talk about daily pain, sorry. 1. What

    is CD? 2. Why do it? 3. How do it? 4. Put it into practice
  3. (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? “ .
  4. 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
  5. 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 !!
  6. Containers (Docker) 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
  7. 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?
  8. 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
  9. 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 All in a matter of minutes No fear to break anything Happy devs + clients
  10. 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?
  11. Development Process Someone needs to ship it. push code open

    PR/MR approve build review feature production system branch server system
  12. 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 * Self-explanatory procedures Don't break conventions Make developers love it!
  13. 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 Registries: http://alternativeto.net/software/docker-hub/ CI Services: http://alternativeto.net/software/travis-ci/
  14. 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/
  15. 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 Transparency: https://painless.software/transparency Monitoring: http://alternativeto.net/software/sentry/
  16. TYPO3 Choices composer 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 ???
  17. 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) Run `cookiecutter gh:painless-software/ painless-continuous-delivery` Then start working immediately!