1. 1. DEPENDENCIES
1.1. no way to test individual features separately, everything is a cluttered mess when multiple features are developed in parallel
1.2. Deployment takes too much time, brains and coordination
1.2.1. deployments sometimes take quite a while
1.2.2. technical and product considerations are mixed up in the decision of "can we deploy to production", making it extremely slow and confusing to make that decision (the technical part should be taken out of that decision, while the product decision should be the only decision necessary)
1.3. Staging is often blocked for production release QA
1.3.1. Not being able to merge b/c not sure about needing to deploy to prod
1.3.2. not visible if we have a feature freeze and what the freeze depends on - only via slack messages
1.3.3. not always visible if deployments are blocked and by what
1.3.4. Introduce hot-fix stage. Have a three stage setup where we keep staging and production, but introduce a hot-fix stage to be able to deploy immediate PRs to production, for bug fixing purpose. Also for release QA to keep staging free for development
1.4. Services have a lot of dependencies which need to be deployed together
1.4.1. Service interdependencies: Do we need to deploy X before Y?
1.4.2. Build software with less dependencies, by building them so they can be used with different versions of the services
1.4.3. Remove deployment dependencies. All services are interconnected. Usually you depend on released services and libs, like we do in the Gemfile. We often make changes that affect multiple services and therefor have deployment dependencies.
1.4.4. if you think about our development as an autobahn where each feature is an individual lane, then i see our deployment as point where all lanes merge to one (master branch). this causes a traffic jam [...]
1.4.5. Small change anomalies: a very small change in nivea-services needs 6 PRs, Approvals, Merges, Waiting for Docker, deploys.
1.4.6. different services are not grouped by a "release" or feature, requiring a lot of manual labor to group them (so that they can be deployed together)
1.4.7. no concept of promoting a tested setup (of different services) to production (like in heroku, a one button promotion)
2. 2. AUTOMATION
2.1. Manually looking for build SHA’s and deploy them after build has been finished is very annoying. A button to deploy automatically the latest build or even a fully automated stage deployment when build is done would be nice
2.2. I would love to have continuous deployment instead of fat releases that probably cause problems that are hard to debug
2.3. no automation except for the docker image building
3. 3. TRANSPARENCY
3.1. Several people deploying at the same time due to missing communication
3.2. which future deployed features are related to other projects? Which projects maybe gets effected by the deployment?
3.3. Make it easier for everyone to know what has been deployed
3.3.1. I may be wrong, but it seems not always clear what is being deployed - as we have many repos, people always have to check and than looks time consuming to me
3.3.2. which features will be deployed?
3.3.3. Is X already deployed with CHANGE on staging/production?
3.4. would be nice to have automatic messages once deployments are done so devs and pms do not communication manually all the time
3.5. => - developer is responsible for a ticket/feature all the way to production - report about it in the standup
4. Next Steps
4.1. Actionable
4.1.1. Give an example how to split a complex feature into independent service releases [norman]
4.1.2. Give an example how API versioning would solve the dependency issues [jaro]
4.1.3. Give an example how a feature flag can help improve the situation [?]
4.1.4. Enforce developer responsibility for a ticket from beginning to production release. Keep board up to date! [PM] Measure cycle time?
4.2. Not yet actionable
4.2.1. Work towards frequent, small releases
4.2.2. Enable independent, one-click deployment of a service
4.2.3. In general: take small steps to improve the situation, the whole system can't be changed right now.
4.2.4. Manage and reduce dependencies
4.2.5. Add automated integration tests
4.2.6. Introduce another deployment stage ("development", "hotfix" or "QA")