8

Problem:

We use Data Transfer Objects (DTO) to ensure consistent interfaces across multiple services using TypeScript.

We're currently using a git subtree in order to make sure that each repository has its DTO dependencies up to date. These DTOs are changed semi-frequently.

The challenging part is that subtree pull / subtree push are outside the traditional git process for most developers.

Question:

What process patterns have people found work well to ensure each related repositories subtree is up to date on each push / pull? Post commit hooks? CI scripts? Etc. etc?

Improve this question
5
  • Why do you use DTOs?
    – 030
    Sep 11, 2017 at 19:30
  • What programming language do you use? Could you example of such a DTO?
    – 030
    Sep 11, 2017 at 19:48
  • martinfowler.com/eaaCatalog/dataTransferObject.html
    – Jack Murphy
    Sep 11, 2017 at 20:06
  • 3
    I don't know what a DTO is, but I would suggest that if you're asking your developers to treat subtrees as anything other than read-only clones you're probably asking for trouble. If developers regularly need to edit files in subtrees directly, or need to update them with something other than git submodule update, people will probably find them hard to work with.
    – larsks
    Sep 17, 2017 at 3:06
  • @larsks In my opinion you could post this comment as an answer.
    – 030
    Nov 24, 2017 at 23:16

1 Answer 1

Reset to default
2

GIT hooks could work, but the trouble is that they're not automatically installed when the developers pulls a workspace. Which means they might end up being installed/used correctly or not. Unreliable.

CI scripts could work as well, but the're reactive, simply indicating that something went wrong, in most cases humans still need to identify the culprit (which might be caused by an improper DTO subtree or by something else) and fix the problem.

If you want your developers to properly pull their subtrees - offer them a scripted wrapper to do so - put the effort into that script so that it is simple to use and robust/working well such that the developer's workflow is effectively simplified. If you manage to do this (most of) the developers will see the benefit and they will use it.

For the push side - you need to take into account that mistakes in push will happen (even with the above-mentioned script, if it's not used by all developers, for example). Everyone makes mistakes.

Personally I favour preventing developers from directly pushing their changes into the integration branch and thus blocking possible mistakes from affecting the integration branch.

Instead I'd have all candidate changes (i.e. either pushed in separate branches or just as diffs) funnelled through a mandatory centralized pre-commit verification system. Automated, of course, with the proper git subtrees management made reliable through that automation. The changes would only be committed/merged into the integration branch automatically by this system, if they meet the quality checks.

This approach is applicable to any potential regression-causing mistakes, not just improper DTO subtrees. An example of such approach would be the gerrit-based development on OpenStack.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.