Branchout
Organise your local environment
Branchout is a wrapper of and helper for several tools, primarily Git, but also Maven and Yarn.
Branchout is a tool for managing Git repositories in organisations that have a lot of them, and doing so in a structured way, commonly called a projected monorepo. Branchout clones all of our repositories in a common folder structure. The result is a consistent layout of source configured to operate with the recommended tooling.
- Consistent naming
- Fast updates
- Single command line view
What does Branchout do
The Branchout script discovers the context by searching for the Branchoutfile and using that to define the cache base directory.
When using branchout mvn to run Maven, Maven is run with -s ~/branchout/practiv/maven/settings.xml which configures it to use a specific local repository directory unique to this branchout tree. If the settings.xml file is missing, then the necessary config is prompted for and the file is created from a template.
branchout maven
Looks like
branchout-maven settings|reactor|<alias>|<maven command>
settings
Generate the maven settings file
reactor
Generate the reactor.xml for the current directory
alias
cv clean verify
cvi clean verify -Pwebapp-interactive
pom help:effective-pom
dep dependency:list
tree dependency:tree
maven command
clean
generate-resources
process-resouces
compile
process-classes
test
prepare-package
package
integration-test
verify
There are a number of aliases, but cv is the most useful, it does a full clean verify cycle which works for any project
Branchout control repository
A branchout control repository is one that contains the manifest and configuration for branchout manyrepo to retrieve and build the project.
- control repository
- Branchoutfile
- Branchoutprojects
- group one
- project one
- project two
- group two
- project three
- project four
Branchoutfile
This is the settings file that branchout consumes to setup your software project.
Branchoutprojects
This is the manifest file that lists the repositories that make up your software project.
Comparision of repo strategies
MonoRepo
A monorepo means you will have one repository with many lifecycles in it
- Easy for developers to get all the code
- Can be hard to grok the tooling, as it will be custom to support the sub projects
- Can still have modular code
- With CI and CD separated the artifacts that come out of CI going into an artifact store
- CI tools don’t tend to work well with Monorepo and need customisation to optimise the build
- Divergent change is hard to manager
https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c https://danluu.com/monorepo/ https://www.atlassian.com/git/tutorials/monorepos
Manyrepo
A manyrepo means each repository corresponds to one output i.e. artifact
- Developers have many repositories to keep track off
- Many IDEs don’t handle manyrepo approaches well, Eclipse is one that handles it very well at the time of writing
- Good for CI
- Good for code hygiene with standard tools
- Need to have good tooling to define inter-repository relationships
- With good tooling handing breaking changes and release automation is fast
https://isacikgoz.me/2019/01/21/polyrepo/ https://news.ycombinator.com/item?id=18808909
Projected Monorepo aka Metarepo
From a developer perspective tooling provides them with a Monorepo locally on disk made up of the Manyrepos in source control