diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md index 8d046208b..13e969f4e 100644 --- a/patterns/2-structured/service-vs-library.md +++ b/patterns/2-structured/service-vs-library.md @@ -42,13 +42,14 @@ do not affect their own downstream customers. Severity levels for the same types of errors may be different across team boundaries due to different SLA definitions per team/customer relationship. +Teams may have different security or regulatory constraints governing their deployments. + ## Solutions Decouple responsibility for source code from deployment: Both teams work to identify exactly where there is overlap and synergies. -Only shared source code is kept as part of the InnerSource project with shared -responsibility. +Only shared source code is kept as part of the InnerSource project with shared responsibility. The shared source should be coherent in that it includes all testing code (including integration tests if available) and as much of the CI pipeline as is possible to make contribution validation easier. Decouple configuration and deployment pipelines from actual business logic. Establish a second deployment of the service for the second team. @@ -56,6 +57,8 @@ 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 ownership. +Deployment configurations can be included as separate projects in your InnerSource portfolio to allow teams to discuss/collaborate or a new team to copy them. + ## Resulting Context Teams are willing to collaborate, benefitting from sharing the work of @@ -71,13 +74,16 @@ The likelihood that changes are needed and made in the shared source code increases, leading to more frequent opportunities to refine, improve and optimise the implementation. +Encourages incremental operational standardisation in release packaging, telemetry, health/readiness endpoints and so on as the teams realise they can more efficiently maintain this in the shared code if they agree on standard conventions. + ## See also Related to this pattern is the [30 Day Warranty](30-day-warranty.md) pattern that takes a different approach to solving the forces described above. ## Known Instances -Europace AG +* Europace AG +* Flutter Entertainment: A [Flutter InnerSource application](https://innersource.flutter.com/start/setup-ci/) has a shared code "service" repository with cross-team contribution and CI pipeline to build and publish a shared release artefact. Each adopting team has a "deployment config" repository defining their own deployment. This is driven by varying regulatory requirements, service and incident management practices and infrastructure skillsets in different areas of the business. ## Status @@ -85,7 +91,8 @@ Europace AG ## Author(s) -Isabel Drost-Fromm +* Isabel Drost-Fromm +* Rob Tuley ## Acknowledgements