Release and-dependency-management memphis python
2 likes473 views
This document summarizes the release and dependency management processes used by a small development team. It describes their Git workflow for new features, including branching, peer review, and merging. It also covers versioning tools, testing on staging servers, production deployment, hotfixes and bugfixes. The document introduces the team's use of Jenkins for continuous integration and delivery. It describes how the team developed a shared "Core" package to organize common code and established version constraints to control dependencies.
Ad
More Related Content
What's hot (20)
Similar to Release and-dependency-management memphis python (20)
Ad
More from Joe Ferguson (20)
![php[world] 2015 Laravel 5.1: From Homestead to the Cloud](https://cdn.slidesharecdn.com/ss_thumbnails/phpworld-2015-laravelhomestead-4x3-151118212002-lva1-app6891-thumbnail.jpg?width=560&fit=bounds)
![php[world] 2015 Training - Laravel from the Ground Up](https://cdn.slidesharecdn.com/ss_thumbnails/phpworld-2015-training-151117190847-lva1-app6892-thumbnail.jpg?width=560&fit=bounds)
Ad
Recently uploaded (19)
Release and-dependency-management memphis python
- 1. Release and Dependency Management Joe Ferguson
- 2. This is not a Code Talk
- 4. “At Scale” http://www.pcmag.com/encyclopedia/term/68176/at-scale “…at the required size to solve the problem…”
- 5. What’s “Enterprise”? http://www.pcmag.com/encyclopedia/term/42637/enterprise Any undertaking or project, with the implication that it is of reasonable size and complexity.
- 6. Everyone is at “Enterprise” “Scale”
- 7. Brands
- 9. Enterprise === A lot http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at- everything.html
- 10. We’re a small(ish) team 2 Front End Devs 6 Back end Devs 1 Architect / Product Manager 1 Manager
- 11. Foundation of our Applications Modern* Well Tested Semantic Versioning Peer Approval Continuous Integration Client Focused Solutions
- 13. Start with a strong version control process/strategy
- 14. New Feature Git Workflow Pull master branch
- 15. New Feature Git Workflow Pull master branch checkout new branch named feature/new-feature-description
- 16. New Feature Git Workflow Pull master branch checkout new branch named feature/new-feature-description change code <where the magic happens>
- 17. New Feature Git Workflow Pull master branch checkout new branch named feature/new-feature-description change code <where the magic happens> Commit changes and open pull request against the develop branch
- 18. New Feature Git Workflow Pull master branch checkout new branch named feature/new-feature-description change code <where the magic happens> Commit changes and open pull request against the develop branch Wait for two peers to approve changes <jeopardy theme plays>
- 19. New Feature Git Workflow Pull master branch checkout new branch named feature/new-feature-description change code <where the magic happens> Commit changes and open pull request against the develop branch Wait for two peers to approve changes <jeopardy theme plays> Merge pull request into the develop branch
- 20. Commit & Versioning Tools
- 21. Emoji in your commits! https://github.com/slashsBin/styleguide-git-commit-message
- 22. Commit tool to automate messages https://github.com/jakeasmith/commit
- 24. Commit tool to automate messages https://github.com/jakeasmith/commit
- 28. Wait for package repo to index new version
- 29. Deployment Cycles, Waterfalls, Sprints, Kanban, and bears oh my!
- 30. Find what works for you
- 31. Kanban Two Week Release Cycle
- 32. Code Freeze and Release Branches Two Week Release Cycle Wednesday before release is a Release Candidate Code Freeze Release branches are created from develop branch Release branches deployed to staging servers
- 33. Testing on Staging Servers Two Week Release Cycle Wednesday before release is a Release Candidate Code Freeze Release branches are created from develop branch Release branches deployed to staging servers Developers & Clients test changes on staging servers & sign off From Wednesday to Tuesday is testing time
- 34. Production Deployment Two Week Release Cycle Wednesday before release is a Release Candidate Code Freeze Release branches are created from develop branch Release branches deployed to staging servers Developers & Clients test changes on staging servers & sign off From Wednesday to Tuesday is testing time Tuesday following the RC freeze is production deploy Release branches are Merged into master via same 2 peer approval pull request process
- 35. Production Deployment Two Week Release Cycle Wednesday before release is a Release Candidate Code Freeze Release branches are created from develop branch Release branches deployed to staging servers Developers & Clients test changes on staging servers & sign off From Wednesday to Tuesday is testing time Tuesday following the RC freeze is production deploy Release branches are Merged into master via same 2 peer approval pull request process Code is deployed to production
- 37. Hotfixes and Bugfixes Hotfixes are branches named hotfix/description that are opened against master Hotfixes are how we patch production
- 38. Hotfixes and Bugfixes Hotfixes are branches named hotfix/description that are opened against master Hotfixes are how we patch production Bug fixes are when we find issues after the RC freeze but before RC branch merging to master Bug fix branches are named bugfix/description that are opened against the release branch
- 39. That’s how we deploy features to our CMS
- 40. Our CI/CD Hero
- 41. Jenkins Automation Build & Run Tests Build Docker Images & Test Build & Deploy Applications Sound the alarms when something breaks Slack Notifications in a CI/CD Channel
- 42. That’s how we deploy features to our CMS, API,
- 43. That’s how we deploy features to our CMS, API, Design Tool,
- 44. That’s how we deploy features to our CMS, API, Design Tool, and other standalone applications
- 45. Architecture CMS API Design Tool A lot of shared logic
- 46. Enter: “Core”
- 48. composer require aol/core *not the actual package name
- 49. Control Version Constraints { "require": { "aol/core": "^17", } }
- 50. Lock To A Minor Version { "require": { "aol/core": “^17.10", } }
- 51. We now have access to all of the logic in Core in all of our applications
- 52. Core Git Workflow No develop branch No Hotfixes, or Bugfix branches All changes are via pull request against master After PRs are approved and merged version tags are bumped Semantic versioning is your friend Individual applications update their own core versions at their own pace (During normal deployment cycles)
- 53. Architecture CMS API Design Tool Core Version 15.1.3 Version 17.6.13 Version 17.0.0
- 54. Remember Scale?
- 55. Core is just another application…
- 56. “Compromise is essential because there are no ideal solutions, only trade-offs” Thomas Sowell - “A Conflict of Vision”
- 58. Joe Ferguson Twitter: @JoePFerguson Email: [email protected] Freenode: joepferguson Contact Info: