It helps to instrument the journey of your work from jira all the way to build, deployment, run and monitoring (observation).
From that you can get measurements on how long each stage takes and the duration of each transition.
From there you can compare team A and B. The transition times is where the human time cost usually sits.
Just getting the time when a Jira or feature is raised, to the time it is picked up to the time of the first commit to the time of the first test and final build does already give you valuable insight.
The points you raised towards the end can be answered if observability of your CI/CD pipeline is actually in place or at least a place to start a line of inquiry.
Naturally the blockers will be aggregated into some of the values but as you work through the journey, they will start clustering at certain stages and maybe highlight a significant problem that needs to be addressed.
There's a wealth of data being left on the table that can help inform management decisions.
This feels all to familiar to a Java developer and similar to what they do in k8s with the genericapiserver component but not to the full extent described in the article. It's interesting to see how the service container pattern appears in other language ecosystems. The nice thing about go's module system is that it feels like a monorepo without the tooling feeling separate to the language. So splitting up a repo into different repos doesn't come with the versioning hell when working with maven
It's been a while since I've looked at Fabric8 but it had good java -> k8s integration and was great for writing k8s tools.
It appears though that Fabric8 is useful for solo java projects without complex dependencies on non-java projects or small java shop. It overlaps with where jenkins-x is going, which has made major strides in the last 24 months.
The original team that worked on Fabric8 lead by James Strachan all moved on from Redhat and many of them are working on Jenkins-x.
Kubernetes is becoming the lingua-franca of building infrastructure. Through CRDs and the kube api spec I can
- start an single application
- deploy a set of interconnected apps
- define network topologies
- define traffic flows
- define vertical and horizontal scaling of resources
And now I can define AWS resources.
This creates an interesting scenario where infrastructure can be defined by the k8s API resources and not necessarily have k8s build it. For example podman starting containers off a K8S deployment spec. It's an API first approach and its great for interoperability. The only downside is managing the yaml and keeping it consistent across the interdependencies.
I've been a big fan of brain storming tools for a long time so appreciate new tools with different takes on the problem.
I do have one observation and it maybe just me. I have no way of clustering a group of connected thoughts, or a way to 'chunk' the concepts. I see some attempt by using coloured lines but there should be a way to make these ideas hierchical and from that be able to zoom up and down various levels of conceptualisation. It would make managing a large network of ideas a lot easier, possibly a bit more ergonomic. Similar to the way the brain works.
It may just be me but was wondering if there's a way to achieve that with the current tooling or if you think there are workarounds?
From that you can get measurements on how long each stage takes and the duration of each transition.
From there you can compare team A and B. The transition times is where the human time cost usually sits.
Just getting the time when a Jira or feature is raised, to the time it is picked up to the time of the first commit to the time of the first test and final build does already give you valuable insight.
The points you raised towards the end can be answered if observability of your CI/CD pipeline is actually in place or at least a place to start a line of inquiry.
Naturally the blockers will be aggregated into some of the values but as you work through the journey, they will start clustering at certain stages and maybe highlight a significant problem that needs to be addressed.
There's a wealth of data being left on the table that can help inform management decisions.