![]() As they say : “it’s not the tool it’s how you use it.” Choose the solution that makes your life easier and assume the responsibilty of learning the accompanying workflow. The important thing to understand is that software integration is never totally painless and there is no perfect cure for the pain. To read more about git subtree - see here. (This depends, of course, on how big your codebase is.) If you find your components are too tightly coupled or you you’re in need of continuous intensive development occurring concurrently in multiple repos you should probably use git subtrees or just spare yourself the headache and drop everything into one big monorepo. In the long run it pays off as integration points can be managed in deterministic manner and with knowledge comes the certainty in the tool. In general : Whenever we want to integrate separate decoupled components with distinct lifecycles I recommend submodules over repo, but their implementation must come with proper education regarding the special workflow they require. Nondeterministic relationship definition (each repo version can be defined as a floating head) Requires an extra repository for management.ģ. Tracking synchronized development effort is easier.Ģ. Need for additional commands (‘clone recursive’ and ‘submodule update’)Ĥ. Developers get confused if they don’t understand the inner mechanics.ģ. (Need separate clones to introduce changes in submodules)Ģ. ![]() Total separation of lifecycles between the parent and the submodules.ġ. Easy to recreate historical configurations.ĥ. Integration points are recorded in parent repo.Ĥ. Deterministic relationship definition (parent project always points to a specific commit in submodule)ģ. An integrated solution, part of git since v1.5Ģ. Still - sometimes this is not an optimal solution, especially if you do a lot of feature branch development (which in itself is an antipattern in classical Continuous Delivery approach – see herefor example).įor these cases we stick to the following guidelines. You can learn more from the Google cloud architect certification. : packaging components to jars, npms, eggs, rpms or docker images, uploading to a binary repo and pulling in as versioned dependencies during the build. This post summarizes the general rules of thumb we at Otomato follow when choosing a solution for this admittedly nontrivial situation.įirst of all – whenever possible - we recommend integrating your components on binary package level rather than compiling everything from source each time. There are a lot of articles on the internet bashing each of the tools, but in our opinion most of it comes from misunderstanding the tool’s design or trying to apply it in an unappropriate context. google repo tool to manage multi-repository integrations in git. I was recently asked by a customer to outline the pros and cons of using git submodules vs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |