Bijna elk team met meer dan één product heeft zo'n repository. Een billing engine die de webshop, het abonnementsportaal en de partner-API allemaal aanroepen. Een componentenbibliotheek die drie frontends importeren. Hij is van iedereen en dus van niemand, en hij gaat meestal stil mis: iemand wijzigt een functiesignatuur voor zijn eigen product, de tests slagen, de wijziging wordt gemerged, en een week later breekt een ander product.
Tot nu toe maakte CodeLynq dat eerder erger dan beter. Een repository hoorde bij precies één project, dus een gedeelde repository was ofwel twee keer gekoppeld, zonder verband tussen de twee, of hij zat in één project en de andere wisten niet dat hij bestond. Dat hebben we goed opgelost.
Eén repository in meerdere projecten
Je kunt een repository nu aan meer dan één project in dezelfde organisatie toevoegen. In de repository-instellingen van een project biedt "Bestaande repository toevoegen" de repositories aan die andere projecten al hebben. De repository houdt één thuisproject, waar de inloggegevens en instellingen beheerd worden; de andere projecten koppelen eraan. Haal je hem weg uit zijn thuisproject, dan verhuist hij naar het volgende project dat hem gebruikt, in plaats van bij allemaal te verdwijnen.
Een gekoppelde repository is een volwaardig onderdeel van elk project. Runs kunnen hem wijzigen, specificaties worden ertegen opgesteld, checks lezen hem en hij staat op de architectuurkaart. De organisatie krijgt ook één pagina Repositories met elke repository en de projecten die hem gebruiken.
Een omschrijving die met de repository meereist
Elke repository heeft een omschrijving die je zelf schrijft: wat het is, wat ervan afhangt, wat niet zomaar mag veranderen. "Billing engine. Bedragen staan overal in centen. De webhook-payload is een publiek contract met twee partners." Die gaat mee in elke prompt die aan die repository werkt, van het opstellen van de specificatie tot de run zelf, in welk project het werk ook begint.
Bij een gedeelde repository voegt de prompt van de run nog iets toe: de namen van de andere projecten die hem gebruiken, en de opdracht om de publieke interfaces (API's, functiesignaturen, schema's, events) backward compatible te houden, of in de samenvatting duidelijk te zeggen wat de andere projecten moeten aanpassen. Dat alleen voorkomt al een hele categorie ongelukken. Niet allemaal, en daarom is er een tweede stap.
Een impact-check zodra de pull request opent
Opent een run in één project een pull request op een gedeelde repository, dan start CodeLynq een impact-check in elk ander project dat hem gebruikt. Voor elk van die projecten:
- kloont hij de repositories van dat project, met de gedeelde repository op de branch van de pull request, zodat de eigen code van het project naast de gewijzigde versie staat;
- draait hij het testcommando van dat project op die combinatie;
- geeft hij een agent die alleen kan lezen de diff, met de vraag elke plek te vinden waar dit project gebruikt wat de diff raakt, imports, API-calls, signaturen, schema's, events, configuratie, en elke plek te toetsen aan de nieuwe code;
- maakt hij van wat breekt een taak in het getroffen project, met een link naar de pull request die het veroorzaakte.
Het moment is waar het om draait. Na de merge is een breuk een incident in het product van iemand anders. Zolang de pull request openstaat, is het een reviewopmerking: de wijziging kan worden aangepast, backward compatible gemaakt, of samen gemerged met een fix aan de andere kant. Bevindingen uit een impact-check worden al vanaf gemiddelde ernst een taak, omdat niemand in het getroffen project weet dat de wijziging eraan komt.
Een check die niets vindt, is een goed resultaat. Raakt de wijziging niets wat het andere project gebruikt, dan moet de agent dat zeggen en geen bevindingen teruggeven, en dat is wat je ziet.
Wat hij niet doet
- Alleen nieuwe pull requests starten hem. Werkt een run verder op een pull request die al openstaat, na reviewopmerkingen of een mislukte CI-build, dan draait de impact-check niet opnieuw. Ook niet voor wijzigingen die mensen zelf pushen; hij hoort bij de run van CodeLynq.
- Hij blokkeert de pull request niet. De resultaten komen als taken in de getroffen projecten. Wie de pull request reviewt, beslist of die erop wacht.
- Hij kost tegoed. Elke check leest een ander project en draait de tests ervan, dus een repository die vijf projecten delen, betekent vier checks per pull request. Daarom kun je hem per repository uitzetten, voor een gedeelde repository waarvan je de wijzigingen al op een andere manier afstemt.
- Hij is zo goed als de tests van het andere project.Zonder testcommando vertrouwt de check op de agent die de code leest, en die vindt gebroken contracten, maar niet elk veranderd gedrag.
Waar je begint
Heb je een gedeelde repository, begin dan met de omschrijving. Schrijf drie of vier zinnen over waar andere producten op vertrouwen, nog voordat je hem ergens koppelt. Het kost niets, het verbetert elke specificatie en elke run die de repository raakt, en tijdens het schrijven komt meestal de ene interface boven waarvan iedereen dacht dat een ander hem stabiel hield. Meer over hoe productteams CodeLynq gebruiken staat op CodeLynq voor productteams.