I'm designing a tool in my organisation to help me with release management. The organisation is composed of several small teams that manage their own repositories in git. The release manager is responsible for cutting branches across all development lines in each of the repositories and then hand it off to QA processes.

The tool asks each team to define a simple YAML spec detailing the steps used to compile and package the team's source into binary artifacts. These could be a maven instruction or a python setup. Different languages (and build tools) are used for each of these projects. The YAML spec and instructions to build/package are stored within individual team repositories.

During a release, my release tool will have to cut branches from all the development branches of these repositories. What I'm struggling with is -- where to store this list of development branches per repository?

It doesn't belong within my tool because I don't want teams to define that list in my tool's source code.

It can't be stored in the repos of the teams because my tool wouldn't know which branch of the team's repo to look at for the development branch information. That's a strange self-reference.

  • A configuration file? – TZHX Jan 21 '17 at 7:41
  • True, but where would it live? Teams shouldn't have to clone the tool's code to change this file though – tsps Jan 21 '17 at 7:42
  • 2
    It's configuring the tool, so in the environment appropriate place (%appdata%, .profile, wherever). Why do you think they'd need to – TZHX Jan 21 '17 at 7:49
  • QA and release management will run this tool to generate artifacts. The development team defines the list of active development branches. They have the freedom to include new ones, deprecate old ones etc. It would help to maintain that list so both parties can focus on what they do without lots of communication involved. – tsps Jan 21 '17 at 13:47

I see 2 different ways to solve this.

  • you can define a standard branch which purpose is to host the code you wish to build. Let's call this branch "delivery". Whenever a development is ready to be built, anyone can merge the dev branch to the delivery branch. When every repository has done so, you can use your tool and configure it to use the delivery branch on each repository.
  • if the solution above can't be used, you can still create a "project" repository which includes every other repository as a submodule. Thus, you can configure your main project and define which branch should be used for each submodule. Finally, your release tool will just have to be configured to use the project repository

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.