Add draft for service-vs-library pattern. - #90
Conversation
Sorry, something went wrong.
| support. This poses a challenge when working across team boundaries: Escalation | ||
| chains may not be the same for errors happening in either team. Coupling | ||
| source code and deployment leaves the teams with the question of who is | ||
| responsible for on-call support in the event of errros. As a result teams are |
There was a problem hiding this comment.
typo: errros -> errors
Sorry, something went wrong.
|
This writeup is good, Isabel. |
Sorry, something went wrong.
| Decouple configuration and deployment pipelines from actual business logic. | ||
| Establish a second deployment of the service for the second team. | ||
|
|
||
| Treat the common base as a library that is used by both teams with shared code |
There was a problem hiding this comment.
The Patlet talks about deploying the same service in independent environments yet the solution talks about factoring out shared service code into a library, which becomes the focus of collaboration (not the service). I feel like these two sections of the document are incongruent with each other. Are the teams collaborating on the source code for a library or a service?
Sorry, something went wrong.
|
@NewMexicoKid Thanks for pointing out the typo. @rrrutledge You're right - these two are incongruent. I've changed the Patlet to be better in line with the proposed solution. Deploying the same service twice with zero modification would presume that deployments are standardised across teams. While this may be true in some cases, more likely than not independent teams will have different deployment environments. Thank you for pointing out that flaw. |
Sorry, something went wrong.
`erros` => `errors`
"interdependent" => "common". I think that "common" is a better word here since the idea is to have a single code base, rather than "interdependent" which signifies multiple code basis that are mutually dependent one on another.
rrrutledge
left a comment
There was a problem hiding this comment.
Seems pretty clear to me. Just one comment.
Also, I accidentally made a commit (cbb2bb2) directly to this branch that I meant to make as a pull request suggestion to the branch. If you don't like it then feel free to revert.
Sorry, something went wrong.
| chains may not be the same for errors happening in either team. Coupling | ||
| source code and deployment leaves the teams with the question of who is | ||
| responsible for on-call support in the event of errors. As a result teams are | ||
| reluctant to join forces even if there is significant overlap in requirements. |
There was a problem hiding this comment.
Another way of getting around this problem is 30-day warranty. Could be good to mention that somewhere in this document.
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks.
Sorry, something went wrong.
|
@rrrutledge I didn't even know that committing to a branch suggested as PR would be possible for the maintainers of the original repository. Learnt something new there. Also, thanks for the corrections you included in your commits. |
Sorry, something went wrong.
rrrutledge
left a comment
There was a problem hiding this comment.
Looks good to me.
Sorry, something went wrong.
|
@rrrutledge thanks for the approval. What does the remaining process for this pull request look like? |
Sorry, something went wrong.
NewMexicoKid
left a comment
There was a problem hiding this comment.
I think this is solid enough to move into the accepted patterns in the main branch. We can pursue a second review at need if people reading the pattern open a PR with suggested changes.
Sorry, something went wrong.
As requested in #89 this is a first draft of the service-vs-library pattern that I observed in DevOps teams.
Feedback, suggestions etc. welcome.