En ändring, flera repon, ingen trasig main

Föreställ dig en funktion som berör ett API, dess klientbibliotek och webbappen. Ge varje repo till sin egen agent med samma vaga beskrivning och var och en gör något rimligt. API-agenten byter namn på ett fält, klientagenten behåller det gamla namnet, webbagenten hittar på ett tredje. Varje agent har rätt i sitt eget repo och fel tillsammans.

Två saker går fel: kontraktet mellan reponarna glider isär, och mergeordningen spelar roll. Mergar du konsumenten före producenten är main trasig tills den andra PR:en landar.

Skriv en överordnad story som beskriver hela ändringen — uppdraget, det nya kontraktet, ordningen — och sedan ett underärende per repo, vart och ett med egna acceptanskriterier. Linear stödjer precis detta med överordnade ärenden och underärenden. [4] Det överordnade ärendet håller arkitekturen; varje underärende är tillräckligt litet för en agentkörning. Hur man skriver vart och ett täcks i vår guide om stories för kodningsagenter.

Det säkraste sättet att ändra ett gränssnitt som flera repon beror på är ett gammalt. Martin Fowler kallar det parallel change:

"Parallel change, även känt som expand and contract, är ett mönster för att implementera bakåtinkompatibla ändringar av ett gränssnitt på ett säkert sätt, genom att dela upp ändringen i tre distinkta faser: expand, migrate och contract." [1]

Varje steg går att driftsätta på egen hand. Googles bok om storskaliga ändringar gör samma poäng i större skala: "den största möjliga atomära ändringen minskar kontraintuitivt" när en kodbas växer, så stora ändringar delas upp i oberoende delar. [2]

Håll inte ordningen i huvudet. I Linear, markera konsument-underärendet som blockerat avproducent-underärendet — blockerade ärenden visas med en orange flagga under "Blocked by" i ärendets sidopanel. [5] Konsumentdelen börjar inte förrän producentdelen har mergats.

Parent: Show customers' chosen display name everywhere
├─ API-1  Expand: accept + return display_name alongside customer_name
├─ SDK-1  Use display_name in the typed client      (blocked by API-1)
├─ WEB-1  Render display_name in account pages      (blocked by SDK-1)
└─ API-2  Contract: remove customer_name            (blocked by WEB-1)

Blocked-by betyder mergad — så se till att mergning av producenten också driftsätter eller publicerar den (för ett SDK, en släppt version) innan konsumentdelen beror på den. Om dina driftsättningar inte sker vid merge, lägg till ett utgivningssteg i producentens story.

Läst uppifrån och ner är det både planen och mergeordningen — och varje rad lämnar main driftsättningsbar. Det är samma idé som att merga parallellt arbete en gren i taget, vilket vi täcker i vår guide om parallella kodningsagenter.

Ett kontrakt skrivet bara i en story kan fortfarande glida isär. Fastställ det i kod, så att en mismatch misslyckas i CI: en delad typad klient genererad från en källa, en OpenAPI-spec som båda sidor validerar mot, eller konsumentdrivna kontrakttester. Pact beskriver idén: ett kontrakt är mellan en konsument — "en klient som vill ta emot viss data" — och en leverantör — "ett API på en server som tillhandahåller den data klienten behöver." [3] Konsumentens tester registrerar vad den förväntar sig; leverantörens CI kontrollerar att den fortfarande levererar det.

Cursors Cloud Agents kan köras i multirepo-miljöer, där en agent ändrar flera repon i en enda körning och öppnar en pull request i varje. [6] När är det rätt verktyg?

Den här guiden kräver två saker: en plan för hela ändringen, och en explicit ordning som håller main driftsättningsbar. Aerunit gör båda. Dess story-skrivare läser varje repo som ändringen berör och föreslår ett överordnat ärende plus ett underärende per berört repo, vart och ett med omfattning, acceptanskriterier och icke-mål.

Aerunit följer Linears blocks / blocked-by-relationer, så när producentdelens PR mergas köas de underärenden den blockerade automatiskt till Cursor Cloud Agents — nästa del börjar ovanpå mergad kod, utan att du dirigerar för hand.