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
SCAB test strategy makes the test code base rigid and costly to evolve when introducing new features. This would sometimes require important refactoring to get new features in
The bar is too high w.r.t. our capacity in osb-cmdb
The expected test code coverage (unit test, component test with CF wiremocks, and acceptance test with live tests) is expensive
The static code analysis (pmd rules, checkstyle, compiler warnings) is strict
The osb-cmdb features don't seem to benefit much to SCAB to justify investment by SCAB maintainers
Osb-cmdb contributions within SCAB code base are slowed down by
Overhead of maintaining/not breaking SCAB features
not used in osb-cmdb:
app brokering
multiple service brokering
future K8S support
pluggeable workflows
seldomly used: configureable brokering (SpacePerServiceOffering vs SpacePerServicePlan)
conflicting requirements:
service instance update optimization
Full non blocking reactor style which are
adding boiler plate code
sometimes restrictive
hard to learn and master
whose benefits does not yet seem to leveraged for osb-cmdb use cases:
no (or few) parallel processing
no backpressure
Possible alternatives
Start from scratch
sc-osb
cf-java-client
Simplify current scab-based osb-cmdb spike ?
Remove unused features
Remove extra layers / modules
Keep focused component / acceptance tests
When to schedule
Now
Before CF V3 API migration
The text was updated successfully, but these errors were encountered:
Expected behavior
As an osb-cmdb contributor, in order to develop new feature and maintain osb-cmdb, I expect the osb-cmdb contributions to be productive
Observed behavior
Effort required to handle Maintain stack, avoid SCAB fork (& changes lack automated test coverage) #6 is still important because
Osb-cmdb contributions within SCAB code base are slowed down by
Possible alternatives
Start from scratch
Simplify current scab-based osb-cmdb spike ?
When to schedule
The text was updated successfully, but these errors were encountered: