Continuos Delivery
Continuous delivery is a software development practice where software can be released to production at any time. The key aspects are keeping software deployable over working on new features, allowing anyone to get automated feedback on production readiness from changes, and performing push-button deployments of any version to any environment on demand. This reduces risks and allows for faster user feedback and believable progress. At MagmaLabs, they implement continuous delivery through feature branches, pull requests, review apps, a protected master branch, and CI/CD pipelines to deploy to staging and production. Lessons learned include advanced sprint planning, trustable tests, review apps using staging data, no development branches, feature switches instead of long PRs, and hotfix branches
Continuos Delivery
- 2. Continuous Delivery at MagmaLabs Edwin Cruz @softr8
- 3. What is Continuous Delivery? Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
- 4. Ah ha? • Your software is deployable throughout its lifecycle • Your team prioritizes keeping the software deployable over working on new features • Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them • You can perform push-button deployments of any version of the software to any environment on demand
- 5. Benefits? • Reduce Risks • Believable Progress • Faster User Feedback
- 6. How we do it
- 8. Workflow • Feature Branches • Pull Requests • Review App per PR • Master Branch Protected • CI with customized flow
- 9. Pull Requests • Engineers check their work on a review app • Product Owner checks acceptance criteria in the Review Apps • CI run tests and linters • Once Approved, PR gets merged
- 11. Review Apps
- 12. Staging Env • After tests are green in master branch, it’s deployed to staging automatically by the CI • QA checks full acceptance criteria including cross browser support • If it is an email template change, we use Litmus
- 13. Sending to Prod • Once QA is done doing its work, they can click in send to production at any time
- 14. Lessons learned • 2 Sprints planned ahead with full acceptance criteria • Trustable Unit & Integration tests • During Sprint planner, re-estimate the effort having a technical discussion • Review Apps, read only data from staging env • No need of development or staging branch • Feature switches instead of long lived PR’s • Hotfixes are branches off git tags