Skip to content

Add Flutter example to Service vs. Library #353

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Sep 13, 2021
Merged

Add Flutter example to Service vs. Library #353

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
be6bb90
Add Flutter example to Service vs. Library
robtuley Sep 9, 2021
961937e
Apply suggested bullets from code review
robtuley Sep 11, 2021
63cdf1d
updated solution language to clarify better
robtuley Sep 11, 2021
f7af976
explain why operational standardisation occurs
robtuley Sep 11, 2021
821d9d2
added external link to further info.
robtuley Sep 11, 2021
170b773
fix md linter suggestion
robtuley Sep 13, 2021
c4fd149
fix md linter suggestion 2
robtuley Sep 13, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions patterns/2-structured/service-vs-library.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,20 +42,23 @@ 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.

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
Expand All @@ -71,21 +74,25 @@ 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

* Structured

## Author(s)

Isabel Drost-Fromm
* Isabel Drost-Fromm
* Rob Tuley

## Acknowledgements

Expand Down