-1

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:

  1. 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.
  2. 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.

  • 2
    Questions asking for general advice are too broad for a Q&A site. Please make your question more specific. – Robert Harvey Sep 11 '16 at 20:40
  • I find it hard to make my question more specific, and I don't know where else I should ask this. I don't have a single issue that needs answering, but I'm actually looking for different ideas on how one (read: people with more experience and which are smarter than me) would implement a manageable and efficient workflow given our requirements and setup. – Jensen Sep 11 '16 at 21:03
  • I've added a TL;DR which I think summarizes my question. Given the wide range of Git development strategies, how should one implement this when a single team develops multiple applications within a single sprint. – Jensen Sep 11 '16 at 21:17
  • You could try asking in the Software Engineering Chat or a forum. – Doval Sep 11 '16 at 21:20
2

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.

Surely this must be possible to do automatically. If anything has been updated in git for develop, release or master then that application is included. And a report can be printed of which systems have changed.

But I don't quite understand how it is not obvious from which user stories/tasks that have been completed in a sprint? Doesn't each story say which part of the system is supposed to be changed? If you just cross check the stories with the list of the applications that are marked as needing to be deployed you will spot the mistakes. It can take at most 30 minutes to do that check.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.