-1

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.

Improve this question
4
  • A configuration file? Commented Jan 21, 2017 at 7:41
  • True, but where would it live? Teams shouldn't have to clone the tool's code to change this file though Commented Jan 21, 2017 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 Commented Jan 21, 2017 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. Commented Jan 21, 2017 at 13:47

1 Answer 1

Reset to default
0

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
Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.