|
I use a very similar system to this one, but instead of building from environment-specific branches, we branch from a release branch. We use a similar git flow system, but we build when a deployable bit of work has been merged into the release branch for this sprint of work (e.g. release-0.1). Once this merge has occurred, a build is triggered, and is then sent to our deployment tool (Octopus Deploy). Our branch naming structure partners with the build number for this specific bit of work to create a build number that matches semantic versioning. From Octopus, we push these releases from our automated dev deployments up to UAT, staging, and eventually to live. Once we have pushed a release to live, the release branch is merged into master, making that release our new master build. When we move on to the next sprint/release cycle, we reset the build number and merge into a new release branch We were keen to use this approach as it allows QA and non-technical people like project managers to deploy releases rather than developers. It was a bit weird to move to a workflow where you never actually deploy from master, but it's worked really well for our use case. It's also reassuring to know that the build that works on your dev box is the exact same build being deployed to your other boxes. With that aside, I definitely agree with the idea behind your post. These are problems that can be solved with existing tools. You can do it using plain-old pull requests, or using a dedicated deployment tool. These tools already have plugins that you can throw into your favoured chat platform, or through email. It seems like there are an ever-increasing number of build/deploy solutions out there that seem to do basically the same thing, but slightly differently. |