experiment(0027): add SDLC experiment with iterative waterfall diagram - #49
experiment(0027): add SDLC experiment with iterative waterfall diagram#49Roming22 wants to merge 1 commit into
Conversation
PR Summary by QodoAdd SDLC experiment docs with iterative waterfall Mermaid diagram (0027)
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
Code Review by Qodo
1.
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
|
@Roming22 and I talked about this privately last week. He wanted to explore the larger SDLC so that we could have a map of all the "places we want to go" - phases of the SDLC that fullsend default agents don't automate today, but which (if our goal is to really automate the entire thing) we should considering building agents for in the future. I suggested that he contribute it to the experiments repo, thinking that it is kind of like a "spike". Some research done. I thought it was probably premature to commit it to the |
| } | ||
| } | ||
|
|
||
| 09.InfoSec |
There was a problem hiding this comment.
[Medium] Non-blocking. The diagram omits a decommissioning/EOL phase — there's no exit from the lifecycle. Every software product eventually reaches end-of-life, and without this the waterfall appears to loop indefinitely. Consider adding a 10.Decommission phase with a transition from 08.Maintenance. Release management (versioning, changelogs) between build and deployment is also absent.
The conclusion acknowledges gaps ("we can't document what we don't know"), but decommissioning is a well-understood process worth including in a reference diagram.
| 05e2e --> 05build: Build release candidate | ||
| } | ||
|
|
||
| state 06.Testing { |
There was a problem hiding this comment.
[Low] Non-blocking. The Testing phase defines three sub-states but no transitions between them, unlike other phases (e.g., Implementation, Planning) that model internal flow. Consider adding transitions to show that e2e gates the others:
06e2e --> 06perf: Stable
06e2e --> 06security: Stable
There was a problem hiding this comment.
That's because in my mind those can happen in parallel. So there is a transition from (Build) Release to Testing, then from Testing to Deployment.
| 06security: Security testing | ||
| } | ||
|
|
||
| state 07.Deployment { |
There was a problem hiding this comment.
[Low] Non-blocking. Same as Testing — Deployment defines six sub-states with no transitions between them. Consider adding minimal transitions to show the flow, e.g.:
07install --> 07config: Configured
07config --> Monitor: Live
Monitor --> 07update: Issue detected
There was a problem hiding this comment.
Some configuration might be needed pre-install, config can be changed post install. A change in the config does not trigger the deployment of new version.
So I left it quite loose on purpose, as it seems a bit hard to model properly.
| What is the big picture of the SDLC process? | ||
|
|
||
| ## Approach | ||
|
|
There was a problem hiding this comment.
[Low] Non-blocking. The Approach section is quite thin compared to other experiments that detail reproducible setups. Since this is a conceptual reference artifact rather than a reproducible experiment, consider adding a HOW_TO.md that clarifies this — e.g., explaining that this is a map of the full SDLC to identify phases where fullsend agents could automate in the future, not a runnable experiment. This would help future readers understand how to engage with it.
rh-pre-commit.version: 2.3.2 rh-pre-commit.check-secrets: ENABLED
3 participants
rh-pre-commit.version: 2.3.2
rh-pre-commit.check-secrets: ENABLED