Add Flutter example to Service vs. Library

[robtuley]

Added Flutter Entertainment experience to the Service vs. Library pattern as this is an approach we use a lot. Our main learning point in this space is to ensure the "shared code" is coherent in that it also includes all testing code (incl integration tests if available) and keep as much of the CI pipeline shared as is possible.

Questions:

• I wasn't sure whether external links from examples are desirable or not: there is further detail here on how we would typically divide CI pipeline steps between shared vs not-shared (plus some of the challenges this approach still has for us) but wasn't sure whether to include it.
• I'm unclear on bulleting conventions -- I wanted to convert various sections of discrete sentence points to be bulleted which I've seen in other patterns but wasn't sure whether to do so, or convert tone into paragraph type linked text instead.

[spier]

This a great example of enriching an existing pattern by adding your implementation of it in your org/context.

To your questions:

• external links => absolutely, go for it (left another comment about that inline)
• bulleting conventions => we don't have explicit conventions about this. However we have often used bullets in Context+Forces (so that those sections become almost a checklist of whether or not the pattern applies to you), while we kept most other sections as regular paragraphs/prose.

Some other question:

If you were to name this pattern, how would you call it?
I am asking because the pattern describes an approach that I might call "Library over Service" or "Separate Service Deployments" or "InnerSource with separate deployments". I don't see the pattern really describing a comparison of InnerSource projects in both release approaches (Library + Service) but rather only focusing on the Library approach.

Do you have any ideas for a visualization that could be helpful to understand the pattern?

Thank you already for this contribution, it makes the pattern better!

[spier]

@MaineC as you are the original author of this pattern it would of course be great to get your feedback. However if you don't have time, I also feel comfortable finishing the review + integration of this PR on my own.

[MaineC]

No need to wait for feedback from original authors - I've really only added my name so ppl know who to blame if it doesn't work ;) Jokes aside, thanks for flagging me anyway - it's great to see this pattern that was developed and published so long ago find adoption in other teams! Thank you for sharing that information @robtuley

[robtuley]

Thanks for the speedy feedback @spier / @MaineC -- various updates applied all of which I agree are improvements.

If you were to name this pattern, how would you call it?

I also find the pattern name confusing, for similar reasons to yourself by the sounds of it. "Service vs Library" sounds like 2 patterns being compared, this pattern is "Library" but that term doesn't describe this pattern well to me personally because it is applied more widely in our context. I'd call this pattern "Separate Team Deployments" or maybe "By Use Deployments", and like your suggestion of "Separate Service Deployments". I can change the name in this PR if you want?

Do you have any ideas for a visualization that could be helpful to understand the pattern?

I've actually got drawing one on our docs backlog for that page linked to, chuckle. The only relevant one I have at the moment is below but I think it lacks context to be used independently.

[spier]

Thanks for working in the feedback @robtuley.

I left two more tiny inline comments, both just fixing issues that our markdown linter is complaining about.

Once those are addressed, then I would say lets merge, to get your improvements in.

For the open questions:

(1) Ideas for alternative pattern names

Renaming the pattern would have consequences in a bunch of places, and we haven't actually done this often enough to have sufficient working knowledge with this. Therefore I suggest that we leave this to a subsequent PR.

I will port our conversation and suggestions from this PR into a new issue, and then we can ask the rest of the community for their input. Might actually be a nice way to engage a broader audience as well and see how they use this pattern and what else they might have to contribute to the pattern.

(2) Visuals

I think with some modifications we could already use your visual as a starting point. Maybe that will also get the creative one's among our pattern readers to suggest improvements to the visual :)

For your visual:

• to confirm: the thing in the middle is the library (shared "Code/Tests"), while the 4 box around it are service deployments by independent teams, all using the library? I am almost sure that my interpretation is wrong, as the boxes "code/test" and "deploy/use" at the bottom don't really fit to that.
• you mentioned "integration tests" to be important. are they part of "tests" in your visual? We could call them out explicitly if we wanted to?

[robtuley]

Committed your suggestions -- sorry until I've contributed once I don't think my pushes trigger the workflows so did not notice the linting fail.

Renaming the pattern would have consequences in a bunch of places, and we haven't actually done this often enough to have sufficient working knowledge with this. Therefore I suggest that we leave this to a subsequent PR.

Sounds good.

[visual] ... to confirm: the thing in the middle is the library (shared "Code/Tests"), while the 4 box around it are service deployments by independent teams, all using the library? I am almost sure that my interpretation is wrong, as the boxes "code/test" and "deploy/use" at the bottom don't really fit to that.

That's right yes -- the context of the visual where I've used it elsewhere is to show how different teams can get involved in various ways. "Normal" is to contribute, deploy and use. But teams can just deploy & use. And we have examples where (project-driven rather than product-driven) teams will contribute to meet a project dependency but they don't actually own a deployment themselves. The "code, test" is because we are good at sharing the source, less good at sharing the (integration) test infrastructure so it's just a nudge reminder on that point! I think I can do a better visual more generally applicable which I'll put in a new PR.