Do components belong in their own source control repo?

[Paul Bouzakis]

After watching some of the clean coder videos on components, it's clear that one application might consist of numerous components.

Since each component should be deployable, I would assume that each component belongs in it's own (github) repository? 

For components that are only ever used in one application, however, I think just having these bundled within app repo also makes sense.

Just wondering how other dev's are breaking out their components and how they are managing these in source control.

[Philip Markgraf]

Independent developability drove us to separate repositories for each component. Otherwise, you end up with unintended connections between the developments (labels for one component applied to all, pull/update/test/push cycle interrupted by the other team, unintentional changes to stable components).

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Caio Fernando Paes de Andrade]

I'm working on a new client that has all components in a single repo. The developers feel the pain every single day. Plus, it gets tricky to setup continuous integration and deployment, so people tend to do things manually most of the time. I strongly advise for separate repos, most modern VCS have the ability to split the files into separate repos while keeping the appropriate commit history, so there's really no reason not to do so.

Caio

[Łukasz Duda]

I try develop components in separate repository (budget and project are separate too) to avoid leaking customer dependencies.

[Łukasz Duda]

Another reason is that you are able see if components are open/closed principle compliant. In order to change them you have to intentionally go to another project. You can't change components accidentally. You are able to "close" them and they become more stable.

[Paul Bouzakis]

Sounds good. Definitely agree on the open/closed adherence. Only push back is that the source code is not as intuitive to navigate thru because of the logic is an external repo's.

[Sebastian Gozin]

Hasn't Uncle Bob at one point made the statement that he shouldbe able to checkout the project and run the build without having to checkout other parts as well?
If we split up the components in different repositories that would be difficult no?

Or perhaps I'm misunderstanding his intentions?

[Caio Fernando Bertoldi Paes de Andrade]

I can checkout component A and run it without checking out its dependency component B, because my dependency resolution tool will download B’s build, not the bare source code.

If I’m working on A and I need to change B, though, then I’ll need to checkout B’s code, change it, publish the changes, start a new build, publish that new build under a new version of B and then update A's dependency file to point to B's new version.

This seems a lot of work, and that’s precisely what Uncle Bob talks about in the Reuse/Release Equivalency Principle. You have to pay this iron price for each component, so they have to be large/relevant/important enough to be worth it.

Having them in separate repos makes the source code and build management easier, and also make the iron price more evident.

Caio

[Łukasz Duda]

I've got one more argument in favor of division into components. If you divide your application, your tests are faster, because they are limited to single component. If you develop single-component application you add tests every day so you test suite slows down.

[Sebastian Gozin]

This price is indeed significant and I feel like the scope of a component as being discussed here has a high chance of being considered not large/relevant/important enough.

Also, for those interested.
If you try to circumvent this price by using dependency version ranges. Because, after all, you're making backwards compatible code changes.
You will eventually blow up the build tools heap and processing time as it tries to make sense of the large hierarchy of dependencies and modules.

Also, if you go the currently popular micro services route you'll be confronted with similar problems/pains.

Caio

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[Tristan Mills]

I've found the cost to be worth it having worked on projects with both styles. My team recently started a new project which took the approach of having each component in a separate repository. This did create some work up front as we learned what belonged where (including some refactoring to break apart one component into more sub components), but now things have settled down we're finding that we rarely need to work on more than one component at a time. The only cases are a couple of components which contain meta-data when adding a new feature.

Dependency management can be a pain, but we're learning how to make it less so.

Contrasting with the multiple components in the same repository - that makes it way too easy to create a mess of code - and this is especially difficult with legacy code and where my colleagues don't use TDD, so refactoring is more difficult and dangerous.

I guess this is another tool in our arsenal for creating and maintaining clean code, there will be cases where it doesn't make sense.

Tristan

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.

[Tomasz Cichecki]

From fitnesse readme:

Apache Ant and a proper internet connection is sufficient to build FitNesse. The build process will bootstrap itself by downloading Ivy (dependency management) and from there will download the modules required to build and test FitNesse.

I think it explains itself. It's definitely a bit more difficult to set up any depedency management tool but if you want to start using or/and fiddling with the project than more or less a push of a button should suffice.

[Sebastian Gozin]

I agree, I've done the module per component approach as well. And yes, you rarely touch more than one module at the same time. And you do learn how to organize those components to avoid unnecessary coupling.
I also used automatic version ranges to facilitate managing dependencies. Hence my remark on the strain on your build tool.

Seeing how Fitnesse uses Ivy...
Ivy is especially bad at dealing with version ranges though. If I'm not mistaken it will touch (HTTP HEAD) every single version known to the repository before settling on the only possible option based on the module metadata.

[Tomasz Cichecki]

The component architecture says nothing about how the source code should be stored. I can imagine that a project can have a build file that has multiple targets and each target can build a module. The build file or some other means can deploy the multiple products of the build separately if they are independently deployable i.e. there's no source dependency among them.
I would move a module into a separte repository only if there are multiple applications that have it as a dependency. In such a case you want it because you will most likely start to build a ceremony around how to introduce a new feature or fix a bug because others depend on its current behavior. For a single application it's an overkill because you simply don't know yet - like with the "reusable framework" from episode 13 :).