From be6bb900831f97e44b3647d23a743caa12a640c6 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Thu, 9 Sep 2021 23:04:27 +0100 Subject: [PATCH 1/7] Add Flutter example to Service vs. Library --- patterns/2-structured/service-vs-library.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md index 8d046208b..2da816e34 100644 --- a/patterns/2-structured/service-vs-library.md +++ b/patterns/2-structured/service-vs-library.md @@ -42,13 +42,15 @@ 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. +responsibility. Test and release packaging should be included in the shared source to allow shared change validation. Decouple configuration and deployment pipelines from actual business logic. Establish a second deployment of the service for the second team. @@ -56,6 +58,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. + ## Resulting Context Teams are willing to collaborate, benefitting from sharing the work of @@ -71,6 +75,8 @@ 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 in the shared code. + ## 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. @@ -79,6 +85,8 @@ Related to this pattern is the [30 Day Warranty](30-day-warranty.md) pattern tha Europace AG +Flutter Entertainment: typical InnerSource application 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 * Structured @@ -86,6 +94,7 @@ Europace AG ## Author(s) Isabel Drost-Fromm +Rob Tuley ## Acknowledgements From 961937e0446f1467d492b6bd81c9404b3fc06d2a Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sat, 11 Sep 2021 20:18:15 +0100 Subject: [PATCH 2/7] Apply suggested bullets from code review Co-authored-by: Sebastian Spier --- patterns/2-structured/service-vs-library.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md index 2da816e34..1d040cbc8 100644 --- a/patterns/2-structured/service-vs-library.md +++ b/patterns/2-structured/service-vs-library.md @@ -83,9 +83,8 @@ Related to this pattern is the [30 Day Warranty](30-day-warranty.md) pattern tha ## Known Instances -Europace AG - -Flutter Entertainment: typical InnerSource application 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. +* Europace AG +* Flutter Entertainment: A typical InnerSource application 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 @@ -93,8 +92,8 @@ Flutter Entertainment: typical InnerSource application has a shared code "servic ## Author(s) -Isabel Drost-Fromm -Rob Tuley +* Isabel Drost-Fromm +* Rob Tuley ## Acknowledgements From 63cdf1d462b4609e50b47883eff794155d0b798a Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sat, 11 Sep 2021 20:27:16 +0100 Subject: [PATCH 3/7] updated solution language to clarify better --- patterns/2-structured/service-vs-library.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md index 1d040cbc8..72dacc6ae 100644 --- a/patterns/2-structured/service-vs-library.md +++ b/patterns/2-structured/service-vs-library.md @@ -49,8 +49,7 @@ Teams may have different security or regulatory constraints governing their depl 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. Test and release packaging should be included in the shared source to allow shared change validation. +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. @@ -58,7 +57,7 @@ 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. +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 From f7af97639c36e9512fcd84a7883ec7e9ad493199 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sat, 11 Sep 2021 20:34:39 +0100 Subject: [PATCH 4/7] explain why operational standardisation occurs --- patterns/2-structured/service-vs-library.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md index 72dacc6ae..f7c15d73c 100644 --- a/patterns/2-structured/service-vs-library.md +++ b/patterns/2-structured/service-vs-library.md @@ -74,7 +74,7 @@ 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 in the shared code. +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 From 821d9d2a41ab23be2693562685f4b5ac1f044963 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sat, 11 Sep 2021 20:45:14 +0100 Subject: [PATCH 5/7] added external link to further info. --- patterns/2-structured/service-vs-library.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md index f7c15d73c..f965aeab9 100644 --- a/patterns/2-structured/service-vs-library.md +++ b/patterns/2-structured/service-vs-library.md @@ -83,7 +83,7 @@ Related to this pattern is the [30 Day Warranty](30-day-warranty.md) pattern tha ## Known Instances * Europace AG -* Flutter Entertainment: A typical InnerSource application 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. +* 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 From 170b7730dae637799abbbbd1336f8fc5fca4b8c5 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Mon, 13 Sep 2021 09:20:28 +0100 Subject: [PATCH 6/7] fix md linter suggestion Co-authored-by: Sebastian Spier --- patterns/2-structured/service-vs-library.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md index f965aeab9..1e0866cfb 100644 --- a/patterns/2-structured/service-vs-library.md +++ b/patterns/2-structured/service-vs-library.md @@ -49,7 +49,7 @@ Teams may have different security or regulatory constraints governing their depl 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. 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. +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. From c4fd1494ad26fbfeb1da320c4ab21f1afbe74386 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Mon, 13 Sep 2021 09:20:57 +0100 Subject: [PATCH 7/7] fix md linter suggestion 2 Co-authored-by: Sebastian Spier --- patterns/2-structured/service-vs-library.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md index 1e0866cfb..13e969f4e 100644 --- a/patterns/2-structured/service-vs-library.md +++ b/patterns/2-structured/service-vs-library.md @@ -83,7 +83,7 @@ Related to this pattern is the [30 Day Warranty](30-day-warranty.md) pattern tha ## Known Instances * 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. +* 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