You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: patterns/2-structured/service-vs-library.md
+11-4Lines changed: 11 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -42,20 +42,23 @@ do not affect their own downstream customers.
42
42
Severity levels for the same types of errors may be different across team
43
43
boundaries due to different SLA definitions per team/customer relationship.
44
44
45
+
Teams may have different security or regulatory constraints governing their deployments.
46
+
45
47
## Solutions
46
48
47
49
Decouple responsibility for source code from deployment: Both teams work to
48
50
identify exactly where there is overlap and synergies.
49
51
50
-
Only shared source code is kept as part of the InnerSource project with shared
51
-
responsibility.
52
+
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.
52
53
53
54
Decouple configuration and deployment pipelines from actual business logic.
54
55
Establish a second deployment of the service for the second team.
55
56
56
57
Treat the common base as a library that is used by both teams with shared code
57
58
ownership.
58
59
60
+
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.
61
+
59
62
## Resulting Context
60
63
61
64
Teams are willing to collaborate, benefitting from sharing the work of
@@ -71,21 +74,25 @@ The likelihood that changes are needed and made in the shared source code
71
74
increases, leading to more frequent opportunities to refine, improve and optimise
72
75
the implementation.
73
76
77
+
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.
78
+
74
79
## See also
75
80
76
81
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.
77
82
78
83
## Known Instances
79
84
80
-
Europace AG
85
+
* Europace AG
86
+
* 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.
0 commit comments