En policy är en namngiven, versionshanterad uppsättning kvalitetsgrindar. Det är policies du kopplar till projekt; grindarna är det som faktiskt körs.
Läs först om begreppen — blockerande kontra rådgivande och var grindarna finns i en körning: Kvalitetsgrindar . Den här sidan handlar om hur du hanterar dem.
Hantera dem i Kvalitetskontroll. I sidomenyn visas organisationens standard och alla projekt. Välj ett för att se hur nytt arbete granskas, vad som kontrolleras vid varje ändring, QA-nivå och var kontrollerna körs. Varje rad har en växel som börjar gälla direkt när du slår om den. Bekräftelsen låter dig ångra ändringen, och inställningarna på en rad ändrar hur kontrollen fungerar.
- Organisationens standardinställning3 projekt följer den2 av 5
- WebbutikEgna inställningar4 av 5
- DokumentationswebbplatsFöljer standardinställningen2 av 5
- Fakturering APIFöljer standardinställningen2 av 5
- MobilappFöljer standardinställningen2 av 5
- Mot slarvSkickar tillbaka en ändring om den försämrar tester, döljer fel, skickar med platshållare eller ökar den strukturella tekniska skulden.
- EnhetstesterHittar och kör repots enhetstester vid varje ändring.
- Webbläsartester2 av 3Avviker från standardinställningenKör dina användarflöden i webbläsaren mot ändringen.
- ÖversättningarAvviker från standardinställningenKontrollerar att ändrade strängar är översatta och att platshållare och pluralformer stämmer överens.
- Kontroller av repositoryKör dina egna kommandon, till exempel för formatering, filstorlek, migreringar, integrationstester och säkerhetsskanningar.
- Noggrann QANoggrannQA samlar in underlag i realtid och skärmbilder utifrån specifikationen. När funktionen är av får arbetet ordinarie QA.
Kvalitetskontroll: gällande policyer och den senaste körningen av kontrollerna. Exempeldata.
Skapa en policy
En policy är en uppsättning kontroller och anger för varje kontroll om ett fel blockerar eller bara ger en varning.
De flesta organisationer behöver två eller tre policies, inte en per projekt:
- en strikt policy för produktionssystem
- en standard policy för allt vanligt
- ibland en enklare policy för interna verktyg och prototyper
Fler än så, och ingen kommer ihåg vilket projekt som har vilken.
Organisationens standard och projektets egna inställningar
Ett projekt följer organisationens standard tills du ändrar en av dess växlar. Då får projektet egna inställningar, kopierade från standarden, och senare ändringar av standarden gäller inte längre för projektet. Du kan kopiera en kontroll från standarden tillbaks till projektet, och via projektets meny kan du återställa hela projektet till organisationens standard. Den fullständiga policyn bakom växlarna, med förväntningar, beroenden mellan kontroller, reparationsbudgetar och versioner, öppnas från samma meny som den avancerade redigeraren. Om projektet följer standarden utgår redigeraren från en kopia av den, och inget ändras för projektet förrän du publicerar kopian.
Använd organisationens standard för dina standard kontroller, alltså de som de flesta projekt bör köra, inte de striktaste. De striktaste bör aktiveras medvetet, projekt för projekt.
Pull requests
Pull requests som personer och andra verktyg öppnar når Coroid via Coroids GitHub App. Gruppen Pull requests under Kvalitetskontroll avgör vad som händer med dem, både för organisationens standard och för varje projekt:
- Coroid Kvalitetskontroll kör kontrollerna ovan för varje pull request och rapporterar resultatet som kontrollen Coroid Kvalitetskontroll på GitHub.
- Coroid Granskning låter Coroids granskare läsa varje pull request och kommentera rader som väcker frågor. Den granskar pull requests som kontrolleras av Coroid Kvalitetskontroll.
Inställningar för Coroid Granskning:
- Vad den publicerar. Rådgivande, standardläget, kommenterar och underkänner aldrig kontrollen. Blockerande begär ändringar när den hittar ett problem, och kontrollen underkänns. Gör Coroid Granskning till en obligatorisk kontroll i GitHub om en blockerande granskning ska stoppa sammanfogningen.
- Vilka pull requests. Som standard väntar den tills ett utkast markeras som redo och hoppar över pull requests som Coroid har öppnat, eftersom Coroids granskare redan har granskat dem under uppgiften. Den kan också hoppa över pull requests från bottar.
- När den granskar. Den väntar en stund efter den senaste pushen, fem minuter som standard. En nyare push ersätter en granskning som inte har börjat. Kör igen på GitHub startar en granskning direkt.
- Granskningsdjup. Hur mycket granskaren får läsa och skriva under en granskning.
Den följer Coroids granskningsregler och reglerna i mappen
review-rules i ditt repo. Ett projekt som följer organisationens standard får standardens
inställningar, precis som för alla andra kontroller.
När något går fel
Tre växlar under organisationens standard gör fel till uppföljningsarbete för alla projekt. Varje växel kör en automatisering som visas under Automatiseringar i Mjukvarufabrik. Agenten läser koden och skapar en uppgift, som går igenom samma specifikation, bygge, verifiering och granskning som alla andra uppgifter.
| Växel | När | Vad agenten gör |
|---|---|---|
| Öppna en åtgärdsuppgift när en uppgift misslyckas | En uppgift misslyckas | Tar reda på varför och skapar, om orsaken finns i koden, en uppgift som åtgärdar felet |
| Utred när en driftsättning misslyckas | En driftsättning misslyckas | Läser vad som ändrades i den versionen och skapar en uppgift som beskriver vad som gick fel och vad som behöver ändras |
| Planera en åtgärd när en release återställs | En release återställs | Skapar en uppgift som dokumenterar vad som återställdes, varför och vad som måste ändras innan det kan släppas igen |
Om du slår av en växel pausas automatiseringen. Slår du på den igen återupptas den. Varje ändring kan ångras. Automatiseringens sida i Mjukvarufabrik visar att den hanteras av Kvalitetskontroll. Att pausa den där är samma sak som att slå av växeln. Om du ändrar instruktionerna blir automatiseringen din egen efter bekräftelse, och växeln slår då inte längre av eller på den.
De här var mallar under Nytt arbete. En automatisering som du skapade från en mall fortsätter att köras. Om du aldrig ändrade den tar växeln över den när du slår på den, i stället för att starta en till. Om du ändrade den förblir den din: växelns rad visar det, och du kan ta över den så att växeln hanterar den.
Rulla ut säkert
Risken med kvalitetsgrindar är inte att de är för svaga. Det är att en välmenande blockerande grind kan stoppa alla uppgifter i organisationen på en gång.
En säker ordning:
- Lägg till grinden som rådgivande.
- Låt den köras på verkligt arbete i en eller två veckor. Läs vad den flaggar.
- Finjustera den utifrån det du har lärt dig.
- Gör den blockerande i ett projekt.
- Rulla ut den bredare när den fungerar som den ska.
- 1Lägg till kontrollenRådgivande
- 2Följ den i en eller två veckorRådgivande
- 3Justera den utifrån vad den flaggarRådgivande
- 4Aktivera blockering i ett projektBlockerandeEtt projekt
- 5Rulla ut den till fler projektBlockerandeFler projekt
Versionshantering och återställning
Policies versionshanteras. Varje ändring med en växel publicerar en ny version, och bekräftelsen låter dig ångra ändringen genom att återgå till den föregående. Äldre versioner kan återställas från versionshistoriken i den avancerade redigeraren.
Återställning gör att du kan publicera beslutsamt. Om en ny grind visar sig vara felinställd räcker det med en åtgärd för att återställa den, i stället för att behöva gräva i historiken.
Undantag
En person med rätt behörighet kan åsidosätta en blockerande grind. Åsidosättningen loggas – vem som gjorde den, när och vad den gällde.
Håll koll på hur ofta grinden åsidosätts. Om den åsidosätts de flesta gånger den utlöses upprätthåller den inga regler; den skapar bara friktion och pappersspår. Åtgärda grinden eller ta bort den.