Rollouts & Migrations
Release and spread of a new feature (system, approach, ...)
Tracking of the spread of a new feature or approach until it's
universally adopted by all relevant consumers
Let's explore couple of real world use cases...
Initial configuration
warning
Async way of retrieving initial configuration complicates consumer
logic and slows down application startup time
construction
Introduce sync way of embedding initial config on the server, adjust
configuration library to provide sync APIs for the consumers and
deprecate async way
Create checks and dashboard to track the migration until is
successful completion, then remove deprecated APIs..
check_circle
Async way of retrieving initial configuration not used by the
consumers. The logic of the configuration lib and consumers was
simplified which leads to less bugs, faster application startup
time!
Core HTTP Interceptors
warning
Every application has to include HTTP interceptors from core lib to
get features like auth, telemetry, …
The lib keeps adding
interceptors for new features but applications often forget to
follow by registering the new interceptor in their own code base.
construction
Create and provide an always up to date DEFAULT_INTERCEPTORS token
in the core lib to be used in place of individual interceptors.
Create checks and dashboard to track the migration until is
successful completion, then make individual interceptors private to
prevent future occurrences
check_circle
Application get every new interceptor feature automatically when
introduced
Skeleton Header
ROLLOUTS example spotlight
Let's imagine a situation when we're developing portal which
consists of many independently developed applications which all
look the same. The users should not be able to tell the difference
when crossing boundary from one application to another.
This is unfortunately not the default case when using many popular
frontend frameworks and libraries like Angular, React or Vue. At
the beginning the page is empty and the content is rendered only
after the boostrap of the used framework or library.
This leaves us with a telling flash of blank page when navigating
from application to another...
Let's solve the issue by providing skeleton header to make
navigation feel seamless for our users.
For example, we can create a dedicated utility library which will
inject up to date skeleton header during the build time. That way
we can also update it in the single place in the future.
With out solution in place, we still need to make sure that all
consumer applications use it in the correct way
To do that we can create new Omniboard check which could look like
the in the example above:
check_circle
Only match projects whose name ends with -spa
check_circle
Match the index.html file (skeleton header has to be
inlined)
check_circle
Check if the skeleton header placeholder was provided
The check will be evaluated against our code bases.
The last step is to use the check to create dedicated dashboard to
track the Skeleton header migration process.
In this case we can use the Progress and
Check results widget to get quick overview.
Don't forget to provide detailed info in the dashboard
description. That way, the dashboard will provide actionable
insight!
Overview, Visibility, KPIs
Environment overview from various unrelated data sources
Collecting information from various unrelated sources to provide
full up to date overview and ability to extract insights to make
better decisions
Project - Team Relationship
warning
Organization with many teams working on even more applications.
Scale makes it impossible to know all the implicit relationships.
Information in wikis gets outdated very fast. Hard to navigate
structure when cooperation is needed.
construction
Define team information as a part of already existing enterprise
specific project metadata file in the project repositories.
Track projects until every project introduced team info in their
metadata file, then create always up to date dashboards with teams
overview
check_circle
Easy to figure out team (and contact person) with help of the Teams
dashboard
Cloud migration
warning
Cloud migration as a nontrivial process of moving applications to
cloud in multiple stages including source code, pipeline to
deployment and switching to cloud core services for utilities like
auth and login. The complex nature of this process makes it very
time consuming to collect data to have a clear picture about the
current state of the progress.
Define collection of Omniboard checks focusing on individual parts
of the process, then create always up to date unified dashboards
with migration progress overview
check_circle
Always up to date migration status can be used to report KPIs, plan,
manage and prioritize further work