In the interest of continuous improvement I'm interested in finding ways to improve our software development process. There are a lot of articles out there which define a set of workflows, but all of them always take the simple approach: 1 repository, 1 team, 1 product, 1 flow. But none of them seem to cover how something like this can be implemented on a larger scale, or when budget is a factor.
We are a small team of developers working on a single product, which consists of multiple applications. When we develop a feature, or fix a bug, then more than one application is impacted. We use scrum with a 2 week development sprint, when we finish our sprint we deploy everything to our QA environment which is then tested during the next sprint. After those two weeks of QA testing we go live.
We have two desktop applications, A and B, used by our employees. Each application has a purpose and a different set of users. We also have a website, C, used by our clients, multiple REST services and a set of Windows services used to perform different scheduled tasks and background processes. In total, we have around 10 applications which all work together and are actively developed.
Each application has it's own Git repository and at least three branches at all time:
- master: corresponds to the production code
- release: corresponds to the version deployed to the QA environment
- develop: corresponds to the version deployed to our test environment
When we work on a new feature, a feature branch is made from the develop branch. A QA bug is fixed on the release branch, merged into develop so that our testers can verify it and only deployed to the QA environment after approval from our testers. A production bug is fixed on master, merged back into develop and release so that the testers and QA can verify and approve, and only then it's published to production.
In practice, it means that a single developer is working on a single feature which spans multiple application and thus multiple repositories. Every application has it's on continuous build plan, where feature branches are automatically discovered and builds take place. Every application also has its own deployment plan. When a feature is finished, the developer merges it into the develop branch and manually starts the deployment plan for the applications which are impacted.
So far, this approach works and handles our multiple application / QA cycle perfectly.
My only problem at this point is the actual deployment process. We use Bamboo, have a deployment build plan and a deployment project which is triggered after the build succeeds. The manual process includes that the developer has to trigger the build for each application themselves. And when we deploy to QA or production, we must rely on the fact that the developer has documented which applications should be deployed this sprint. And sometimes mistakes are made or an application is forgotten. We also don't have the financial resources to simply set up new servers for every feature branch we create, so that's a possible issue.
So, I'm interested in knowing if:
- Someone has an idea how we can improve or change or flow. Our major bottleneck is that we can't perform production deploys during office hours. So deploy on commit to production is not really an option for our master branch.
- Are there tools (like Octopus deploy or the likes) which would make our deployment life easier? I've already thought about creating a simple webpage were we can list releases, and use Bamboo's REST API to trigger the deployment builds for every application, but I prefer to use an existing flow/product.
I have been playing around with the idea of creating a single, massive, build plan which performs the actual deploys, but something just screams "wrong" about that idea.
TL;DR: How can we efficiently implement a git branching strategy and deployment process across multiple repositories containing multiple applications developed within the same sprint?
Any pointers or ideas are appreciated, and if you down-vote my question, please comment and explain why.