More frequent deployments #598
shawncrawley
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'd love to see us get into the groove of more frequent deployments. I understand that we want to maintain a high level of stability and confidence in what we push out, but I feel like some of the most rapid-feedback, low-hanging fruit issues (and sometimes features) are often simple tasks that could likely be completed in a single day. I personally don't feel super motivated to tackle those small tasks when I know that they will not get deployed for maybe weeks after the work is finished. I know this is a psychological thing, since either way the work is required of me, but there's power in psychology. I'd think we'd want to tap into that positive psychological energy to build more forward momentum across our team and work.
Maybe ideally we could get to the point of being able to deploy any given feature from TI to UAT and then on to Production as soon as it is deemed ready, whether it's a short-term, quick task or a long-term slow task. I feel like the main complicating factor there is the branching/committing/merging strategy we commit to using. Assuming everything was developed perfectly the first time - at the moment a feature branch is merged into the
ti
branch - then there'd be no problem. It's the discovery of bugs in either TI or UAT that complicate things. Namely, since at that point the code base could have a combination of bugfix/feature commits that both do work and don't work, making merging theti
branch intouat
or theuat
branch intoprod
a pain since you'll either have to delay the merge until all the issues are fixed, or do one or more "undo" commits to back out the problematic commits.Anyway, food for thought. I'd love to flesh these details out and see what could make work for us. Anyone have any additional thoughts or ideas?
Beta Was this translation helpful? Give feedback.
All reactions