Use cases / Before a release ships
Every check is green on a column drop. Does anything still read it?
A cleanup pull request drops an old column and passes every check, but the checks cannot see the other repositories and the old instances that still read it.
Jigward searches every connected repository, finds two readers and leaves a comment-only review with a two-release order on the line that drops the column. Approval and the release order stay with the engineering lead.
The film
Chapters
Read the narration
0:00 Green checks, one question
I'm Jigward. Ethan's cleanup removes an old database column, and every automated check is green. Before Maya signs off, she asks me: does anything still read it?
0:12 What the pull request and the schema show
Let's see what it changes. The checks ran on an empty database, and it drops the column and the field that maps it in one release. In billing's own schema, only an index uses that column. And an index usually means somebody filters by it.
0:34 A reader in another repository
The checks only see this repository. The team connected four, so I search all of them. One match outside billing, in the platform repository. There it is: the nightly billing export selects the column and filters on it. After the release, that export would fail. I'll record a proposal for the platform team.
1:00 The rule the team agreed, and a two-release plan
The team already agreed how to drop a column: stop reading it, then drop it a release later. During a rolling deploy, old instances still read it. I comment on the line that drops it, naming both readers and a safe order. The export changes first, otherwise its filter ignores new customers. Approval stays with Maya.
1:24 Not yet, and who sets the order
Maya gets a direct answer in the original thread: not yet, with the evidence linked. A clean search isn't proof, so I also list everything I couldn't verify. Ethan splits his pull request, and Maya decides the release order. The cleanup still happens; the column only disappears once nothing is reading it.
What changes
Today. The author searches their own repository, CI applies the migration to an empty database, and the reviewer trusts both, searches the other repositories by hand or asks in a channel and hopes the right person answers. CI and migration linters look at one repository and an empty schema. A linter may warn that a drop is risky, but it cannot see who reads the column from another repository, so a miss turns up as a failed deploy or a failed export the next night.
-
Before: Approving a green pull request because the author found no reader in one repository.
With Jigward: All four connected repositories searched, and both readers named at file and line.
-
Before: The column and the field that maps it removed in one release, while old instances still read it.
With Jigward: A two-release order on the line that drops it. The export moves first, the field goes next, the column a release later.
-
Before: A rule about dropping columns that only some reviewers remember.
With Jigward: The decision the team recorded five months earlier, applied to this pull request with its source.
What Jigward does
@Jigward before I approve the cleanup that drops legacy_status, does anything still read that column? Is it safe to drop?
Connected beforehand
- Four repositories, billing among them, are connected through GitHub and held in one Context.
- The team channel is named for that Context.
-
Reads the pull request
The change drops the column and removes the field that maps it in the same release. The checks ran the migrations on an empty database.
-
Reads the schema
In the schema the billing service's Liquibase migrations define, only an index uses the column. An index usually means some query filters on it.
-
Searches every repository
The checks saw one repository. The Context holds four, so Jigward searches all of them and finds one match outside billing, in the platform repository.
-
Finds the first reader
The nightly billing export selects the column and filters on it, so its next run after the drop would fail. The fix belongs to another team, so Jigward records it as an initiative instead of changing their code.
-
Applies the team's rule
In memory, Jigward finds the team's decision to drop a column one release after code stops reading it, because old instances keep serving during a rolling deploy. That makes the old instances the second reader.
-
Comments, then answers
A comment-only review on the line that drops the column names both readers and an order. The export changes first, or its filter would skip new customers. In the thread, the answer is not yet, with what was not checked.
Jigward in this case
-
Slack
The question arrives as a mention in the team channel, and the answer goes back to its thread.
-
Tasks
The mention becomes a Task that changes nothing. It keeps every search, each file read and the review.
-
Project knowledge
The schema that billing's Liquibase migrations define shows the index on the column.
-
GitHub
Jigward searches the four connected repositories, reads the export at a named commit and posts a comment-only review. It never approves or blocks.
-
Memory
The team's rule for dropping columns comes back with who recorded it and when.
-
Initiatives
The export change is kept as an initiative, with the file and lines, for the team that owns the export to take up or decline.
What comes back, and what stays with the team
What comes back
- GitHub A comment-only review on the line that drops the column, naming both readers at file and line and the order that lets the drop ship.
- The team thread in Slack A direct answer, not yet, linking the pull request, the Task and the initiative, with what was not checked.
- Home in Jigward An initiative to move the nightly export off the old column, with the file and lines it rests on.
What the team decides
- How to split the pull request. That is the author's call.
- When to approve and in what order the releases go. Both stay with the engineering lead.
- Whether the team that owns the export takes up the initiative. Jigward approves, blocks and merges nothing.
What Jigward did not check
- Ad-hoc SQL that people run by hand.
- BI tools and their dashboards.
- Production data, and databases outside these repositories.
- Readers a code search cannot find. A clean search is evidence, not a certainty.
Meet your next engineering coworker
Bring a question
from your own project.
See how Jigward can help your team understand the system and move the next task forward.
Jigward is in closed testing. Accounts are created by hand; sending a request does not create one.