Aanbevelingen voor het standaardiseren van hulpprogramma's en processen

  • Artikel

Van toepassing op deze aanbeveling voor de controlelijst voor operationele uitmuntendheid van Azure Well-Architected Framework:

OE:04 Optimaliseer softwareontwikkelings- en kwaliteitsborgingsprocessen door bewezen procedures voor ontwikkeling en testen te volgen. Voor ondubbelzinnige roltoewijzing standaardiseert u procedures voor onderdelen zoals hulpprogramma's, broncodebeheer, toepassingsontwerppatronen, documentatie en stijlhandleidingen.

Gerelateerde handleiding: De snelheid | van de build verbeterenContinue integratie gebruiken

In deze handleiding worden de aanbevelingen beschreven voor het definiëren van standaarden voor hulpprogramma's en processen voor softwareontwikkeling. Het definiëren van consistente procedures leidt tot een efficiënt workloadteam en werk van hoge kwaliteit. Goed presterende teams gebruiken bewezen hulpprogramma's en processen om verspilling van werk en mogelijke codefouten tot een minimum te beperken.

Belangrijke ontwerpstrategieën

De eerste stap bij het optimaliseren van ontwikkelprocedures is het standaardiseren van hulpprogramma's en processen. Gebruik indien mogelijk in de branche bewezen oplossingen in plaats van interne oplossingen te ontwikkelen. Als u uw procedures verder wilt optimaliseren, moet u hulpprogramma's met weinig code en zonder code gebruiken. Met deze hulpprogramma's kunt u zich richten op uw toepassing en tijd besparen. Voor alle hulpprogramma's en processen die u standaardiseert, implementeert u training zodat uw teams deze begrijpen en efficiënt gebruiken. Houd rekening met de volgende aanbevelingen om standaarden te definiëren die u helpen bij het optimaliseren van uw ontwikkelprocedures.

Gebruik bekende en volwassen standaardtools

Gebruik bekende en volwassen standaardtools en standaardiseer het gebruik ervan. Zeer effectieve technische teams gebruiken de beste hulpprogramma's. Deze aanpak minimaliseert de noodzaak om oplossingen te ontwikkelen voor planning, ontwikkeling, testen, samenwerking en continue integratie en continue levering (CI/CD). Veel ondernemingen geven ontwikkelaars de keuze tussen een paar hulpprogramma's, maar alle opties zijn standaardhulpprogramma's voor de organisatie en worden intern gevalideerd. Het belangrijkste is dat u hulpprogramma's kiest die voldoen aan de vereisten voor uw workload. Standaardhulpprogramma's moeten de volgende functies bieden:

  • Werkplanning en achterstandsbeheer

  • Versiebeheer en opslagplaatsen

  • CI/CD-pijplijnen

  • Testen, zoals integratie, rook, synthetische gebruiker, simulatie, chaos en andere kwaliteitstests

  • Codeontwikkeling

In sommige gevallen kan één hulpprogramma of een reeks hulpprogramma's verschillende functies bieden. Zorg ervoor dat u de mogelijkheden van uw hulpprogramma's en hun beperkingen begrijpt, zodat ze voldoen aan uw vereisten voor verschillende functies.

Bepaal of u moet investeren in dure hulpprogramma's of premium-versies van hulpprogramma's. Houd rekening met de tijd en moeite van het ontwikkelen van uw eigen oplossingen in vergelijking met de functies die de premium-hulpprogramma's bieden. Houd rekening met eenmalige kosten versus terugkerende kosten. In de meeste gevallen bieden standaardhulpprogramma's een hogere waarde voor uw team.

Gebruik hulpprogramma's met weinig code, geen code en AI-hulpprogramma's wanneer dit praktisch is. Hulpprogramma's met weinig code en zonder code besparen ervaren ontwikkelaars tijd doordat ze eenvoudig functionaliteit kunnen inschakelen in plaats van het hele codeontwikkelingsproces uit te voeren. Met deze hulpprogramma's kunnen ook workloadteamleden die mogelijk geen ontwikkelaars zijn opgeleid, bijdragen aan de werking van de workload. AI-hulpprogramma's kunnen helpen bij het ontwikkelen, beoordelen en optimaliseren van code.

Uw vertakkingsstrategie standaardiseren

Kies indien mogelijk een model op basis van een trunk. Vertakking op basis van trunks houdt het ontwikkelteam van de workload synchroon en stimuleert continue levering. Definieer vertakkingsbeleid om belangrijke vertakkingen te beveiligen, zoals de hoofdvertakking. Zie Een Git-vertakkingsstrategie gebruiken en Vertakkingsbeleid en -instellingen voor meer informatie.

Metrische gegevens evalueren om de effectiviteit van de ontwikkeling te kwantificeren

Softwareontwikkelings- en kwaliteitsbewakingsteams kunnen alleen verbeteren als ze hun effectiviteit kunnen kwantificeren. Om de effectiviteit te kwantificeren, moeten ze de metrische gegevens identificeren die de snelheid van ontwikkelaars meten en KPI's definiëren. Voorbeelden van deze metrische gegevens zijn:

  • Implementatiefrequentie: het aantal implementaties dat elke ontwikkelaar elke dag implementeert.

  • Doorlooptijd: de tijd die nodig is voor een taak of gebruikersverhaal om van de achterstand naar een productie-implementatie te gaan.

  • Gemiddelde tijd tot oplossing: de gemiddelde tijd die is besteed aan het oplossen van fouten of defecten in code.

  • Foutpercentage wijzigen: het percentage wijzigingen dat resulteert in een fout.

Om belanghebbenden en het workloadteam te helpen bij het bijhouden van de snelheid, visualiseert u KPI's met behulp van dashboards of andere rapportagehulpprogramma's.

Standaardiseren hoe uw workloadteam code schrijft, beoordeelt en documenteert

Standaardiseer hoe uw workloadteam code schrijft, beoordeelt en documenteert met behulp van een stijlhandleiding. Een standaardstijl maakt samenwerking eenvoudig en helpt bij het onboarden van nieuwe ontwikkelaars. Om effectief te kunnen werken, moeten nieuwe ontwikkelaars weten hoe het workloadteam werkt. Een stijlgids met duidelijk gedefinieerde standaarden kan hun trainingsproces vereenvoudigen. Definieer in de stijlhandleiding standaarden voor ontwikkeltalen, bibliotheken, frameworks en andere conventies.

Wanneer het praktisch is, gebruikt u hulpprogramma's om standaarden voor codeopmaak af te dwingen. Visual Studio biedt bijvoorbeeld verschillende hulpprogramma's waarmee code wordt gescand op stijl, kwaliteit, onderhoudbaarheid, ontwerp en andere problemen. Voor infrastructuur als code (IaC) kunt u Checkov of Terrascan voor Terraform gebruiken.

Om consistentie te garanderen en mogelijke verwarring te voorkomen, moet de stijlhandleiding standaardnaamconventies bevatten voor artefacten, omgevingen, vertakkingen, builds en uitvoeringen.

U moet ook richtlijnen en standaarden instellen voor de toegestane mate van variantie in uw omgevingen. Als er nieuwe talen, frameworks of andere technologieën zijn die leden van het workloadteam willen toevoegen aan de standaardlijst, implementeert u een proces voor het gebruik van deze hulpprogramma's in een sandbox of een lagere omgeving. Test de levensvatbaarheid ervan en vervang bestaande technologieën indien nodig.

Gebruik architectuurbeslissingsrecords (ADR's) om een historisch overzicht bij te houden van de ontwerpbeslissingen van uw workloadteam. ADR's helpen uw teams een nieuw inzicht te krijgen in de workload. Ze helpen nieuwe teamleden ook meer te weten te komen over de ontwerpbeslissingen die worden genomen tijdens de levenscyclus van de workload. Zorg ervoor dat ADR's versiebeheer hebben.

Neem in uw ADR het volgende op:

  • Specifieke hulpprogramma's en technologieën, bijvoorbeeld met behulp van SQL of NoSQL, die uw team kiest.

  • De redenen voor de beslissingen van uw team.

  • Andere opties die zijn overwogen, die helpen bij het contextualiseren van de uiteindelijke beslissing.

  • Functionele en niet-functionele vereisten die worden meegenomen in beslissingen.

  • De context van het besluitvormingsproces, zoals het probleem dat is aangepakt.

Standaarden implementeren voor het aanpakken van technische schulden

Ga ervan uit dat technische schulden opzettelijk en noodzakelijk zijn voor de producten van uw workloadteam. Deze mindset motiveren uw team om technische schulden regelmatig te overwegen en aan te pakken om accumulatie te voorkomen. Technische schulden aanpakken als een regelmatig terugkerende taak in de achterstand.

Stel dat uw team is gestandaardiseerd voor een bibliotheek. Na verloop van tijd moet u overschakelen naar een andere bibliotheek voor nieuwe functionaliteit in de workload. Deze overgang kan leiden tot technische schulden. Vaak kunnen overgangen zoals deze het workloadteam twee technologieën laten ondersteunen, omdat ze niet volledig soepel kunnen overgaan. Het workloadteam moet prioriteit geven aan het voltooien van de overgang, omdat wanneer de workload de nieuwe functionaliteit bereikt, belanghebbenden tevreden zijn en minder snel rekening houden met de technische schuld.

Standaardiseren hoe u versiebeheer toepast op uw artefacten

Standaardiseer hoe u versiebeheer toepast op uw artefacten en hoe versiebeheer intern en extern beschikbaar wordt gemaakt. Clientgerichte systemen moeten bijvoorbeeld hun actieve versie beschikbaar maken in de gebruikersinterface. Deze techniek is handig wanneer het workloadteam problemen oplost, omdat de klant eenvoudig kan communiceren welke versie ze gebruiken. REST-interfaces kunnen versies voor bepaalde onderdelen of databases beschikbaar maken. U kunt een specifieke tabel in de metagegevens voor een schema gebruiken om de schemaversie beschikbaar te maken.

Gebruik in de branche bewezen ontwerppatronen voor toepassingen om ervoor te zorgen dat uw toepassing betrouwbaar, presterend en veilig is. Gebruik deze patronen om tijd en moeite te besparen in vergelijking met het ontwikkelen van uw eigen oplossingen voor uw toepassing. Kies de patronen die uw workload ten goede komen. Controleer regelmatig ontwerppatronen om ervoor te zorgen dat u de juiste patronen gebruikt naarmate uw workload zich ontwikkelt.

Een shift-left-benadering voor testen implementeren

Implementeer een shift-left-benadering voor testen door in een vroeg stadium en vaak tijdens het ontwikkelingsproces eenheidstests uit te voeren. Door regelmatig te testen in elke ontwikkelomgeving krijgen ontwikkelaars vertrouwen in hun toepassingen. Houd rekening met de volgende principes om uw teststrategie te maken met een shift-left-benadering:

  • Schrijf tests op het laagst mogelijke niveau. Geef de voorkeur aan tests met de minste externe afhankelijkheden en voer tests uit als onderdeel van de build.

  • Schrijf tests eenmaal en voer overal tests uit, inclusief productie. Schrijf tests die u in elke ontwikkelomgeving kunt uitvoeren zonder rekening te houden met factoren die specifiek zijn voor één omgeving, zoals versleutelde geheimen of configuraties.

  • Ontwerp uw workload voor testen. Maak testbaarheid een vereiste wanneer u uw toepassing ontwikkelt.

  • Testcode behandelen als toepassingscode. Pas dezelfde kwaliteits- en ontwikkelingsstandaarden toe op toepassingscode en testcode. Testcode naast toepassingscode opslaan. Ontwikkel en onderhoud testcode met toepassingscode. Verwijder tests die niet betrouwbaar zijn om de kwaliteit van de tests te garanderen.

  • Overweeg het eigendom van de test, die is gebaseerd op het eigendom van de workload. Uw workloadteam is eigenaar van hun tests en mag niet vertrouwen op andere teams om hun code te testen.

  • Automatiseer tests zoveel mogelijk. Geautomatiseerde code ontlast uw workloadteam en dwingt consistente kwaliteit af.

Zie Shift testing left with unit tests (Shift testing left with unit tests) voor gedetailleerde richtlijnen over het implementeren van een DevOps-teststrategie.

DevSecOps-procedures vereisen als onderdeel van uw standaard bedrijfsprocedures. Uw workloadteam moet inzicht hebben in de beveiligingsprocedures met betrekking tot softwareontwikkeling en kwaliteitsbewaking. Ze moeten deze procedures zonder uitzondering volgen. Zie De levenscyclushandleiding voor beveiligingsontwikkeling voor meer informatie.

Standaarden implementeren voor het benoemen en taggen van resources

Het implementeren van label- en naamconventies is een best practice voor het beheren en organiseren van Azure-resources. Label- en naamconventies helpen bij het identificeren, classificeren en groeperen van resources op basis van algemene kenmerken, zoals omgeving, toepassing, eigenaar of kostenplaats. Ze maken ook beveiliging, automatisering, rapportage en governance van resources in abonnementen en resourcegroepen mogelijk.

Enkele voordelen van het gebruik van gestandaardiseerde labels en naamconventies zijn:

  • Ze bieden consistentie en duidelijkheid voor resource-identificatie en -beheer, waardoor detectie en zoekopdrachten in de Azure Portal, PowerShell, CLI en API's worden vergemakkelijkt.
  • Hiermee kunt u resources filteren en groeperen voor facturerings-, bewakings-, beveiligings- en nalevingsdoeleinden.
  • Ze ondersteunen levenscyclusbeheer van resources, zoals inrichten, buiten gebruik stellen, back-up en herstel.
  • Ze zijn essentieel voor beveiligingsdoeleinden. Als u te maken krijgt met een beveiligingsincident, is het essentieel om snel de betrokken systemen, de functies die deze systemen ondersteunen en de mogelijke bedrijfsimpact te identificeren.

Zie Uw naamconventie definiëren voor meer informatie over het gebruik van naamconventies voor uw cloudresources. Zie Uw tagstrategie definiëren voor meer informatie over het toepassen van metagegevenstags op uw cloudresources.

Azure-facilitering

  • Azure DevOps is een verzameling services die u kunt gebruiken om samen, efficiënt en consistent te ontwikkelen. Azure DevOps bundelt de volgende oplossingen:

    • Azure Pipelines biedt build- en releaseservices ter ondersteuning van de CI/CD van uw toepassingen.

    • Azure Boards is een webhulpprogramma voor werkbeheer dat ondersteuning biedt voor Agile-procedures zoals Scrum en Kanban.

    • Azure-opslagplaatsen is een hulpprogramma voor versiebeheer dat ondersteuning biedt voor het gedistribueerde versiebeheersysteem van Git en het Team Foundation-versiebeheersysteem .

    • Azure Test Plans is een op een browser gebaseerde oplossing voor testbeheer die mogelijkheden biedt die vereist zijn voor gepland handmatig testen, testen van gebruikersacceptatie, verkennende tests en het verzamelen van feedback van belanghebbenden.

    • Azure Artifacts wordt gebruikt om ontwikkelaars in staat te stellen hun code efficiënt te delen en hun pakketten te beheren.

  • GitHub Actions voor Azure is een hulpprogramma dat u kunt gebruiken om CI/CD-processen te automatiseren. Het integreert rechtstreeks met Azure om implementaties te vereenvoudigen. U kunt werkstromen maken die elke pull-aanvraag naar uw opslagplaats bouwen en testen, of samengevoegde pull-aanvragen implementeren in productie.

  • GitHub Projects is een hulpprogramma voor werkbeheer dat u kunt gebruiken om kanbanborden, rapporten, dashboards en andere functies te maken.

  • Hulpprogramma's met weinig code en zonder code zijn onder andere:

  • Azure Resource Manager-sjablonen en Bicep zijn azure-systeemeigen hulpprogramma's die u kunt gebruiken om IaC te implementeren. Terraform is een ander door Azure ondersteund IaC-hulpprogramma dat u kunt gebruiken voor het implementeren en beheren van infrastructuur.

  • Visual Studio is een robuust ontwikkelhulpprogramma dat kan worden geïntegreerd met Azure en ondersteuning biedt voor veel talen.

  • GitHub Copilot is een AI-service die fungeert als pairprogrammeur en suggesties voor automatisch aanvullen biedt terwijl u codeert. Copilot is beschikbaar als extensie in Visual Studio en verschillende andere ontwikkelhulpprogramma's.

  • Azure Load Testing is een volledig beheerde service voor belastingstests die u kunt gebruiken om grootschalige belasting te genereren door verkeer voor uw toepassingen te simuleren, ongeacht waar ze worden gehost.

Uitlijning van de organisatie

De Cloud Adoption Framework voor Azure biedt algemene richtlijnen en aanbevelingen voor het taggen en benoemen van Azure-resources, evenals specifieke regels en voorbeelden voor verschillende resourcetypen.

Controlelijst voor operationele uitmuntendheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor operationele uitmuntendheid