Miljøer til udviklerkodning
Inden for platformkonstruktion er en af de almindelige udfordringer at sikre, at udviklere hurtigt og konsekvent kan konfigurere deres kodemiljøer, især når nye udviklere tilmelder sig teams, udviklere skifter mellem projekter, eller der er behov for at skalere. Automatisering af konfigurationen af udviklermiljøer kan strømline onboarding og eliminere tabt tid på grund af fejlkonfigurationer eller brudte afhængigheder. Ved at levere forudkonfigurerede miljøer eller konfigurationsscripts kan teams fokusere på udvikling i stedet for at spilde tid på fejlfinding af miljøkonsekvenser.
Tilgangen til administration af udviklermiljøer kan variere, men den omfatter ofte virtualisering, objektbeholderisering og standardiserede skabeloner, der stemmer overens med organisationens behov. Dette kan variere fra fuldt virtualiserede Windows-miljøer til cloud-hostede objektbeholdere til Linux-udvikling. Derudover er oprettelse af "start til højre"-skabeloner, der fremmer ensartethed, bedste praksis og sikkerhed som kode afgørende for at opretholde en veldefineret, gentagelig proces, der skaleres på tværs af teams. Dette sikrer, at udviklingsarbejdsprocessen ikke kun starter gnidningsløst, men fortsat overholder bedste praksis, så projekter holdes på sporet og overholder sikkerhedsstandarder og driftsstandarder.
Automatiserer konfiguration af udviklerkodningsmiljø
Opstart og normalisering af udviklerkodningsmiljøet kan være en stor udfordring i teknikersystemer. De vigtigste problemer omfatter:
- Lange onboardingtider: Det kan tage uger, før en ny udvikler bidrager, især når udviklere overføres mellem projekter eller underleverandører.
- uoverensstemmelser: Forskelle mellem udviklermiljøer og CI-systemer fører ofte til problemer med "det fungerer på min maskine".
- Ustabilitet i miljøet: Eksperimenter med eller opgradering af strukturer og software kan ødelægge eksisterende konfigurationer, hvilket kan resultere i langvarig og kompleks fejlfinding.
- Forsinkelser i kodegennemgang: De konfigurationsændringer, der er nødvendige for kodegennemgange, kan sinke udviklingen, da de skal fortrydes senere.
- ramp-up for alle interessenter: Ikke-udviklingsroller (f.eks. operatører, QA og forretningssponsorer) skal også oplæres og engageres, hvilket medfører flere forsinkelser.
Du kan løse disse problemer ved at standardisere og automatisere konfigurationen af udviklermiljøer via værktøjer, scripts eller objektbeholdermiljøer/virtualiserede miljøer. Forudkonfigurerede miljøer, der er skræddersyet til specifikke projekter eller organisatoriske behov, kan sikre ensartethed, reducere installationstiden og forbedre den overordnede produktivitet.
Kodemiljøer til Windows og Linux
Når du målretter Windows til erstatning af arbejdsstation eller fuld virtualisering, giver virtuelle maskiner (VM'er) generelt den bedste funktionalitet. Denne fremgangsmåde er nyttig for Windows-klientudvikling, administration af .NET Full Framework-webprogrammer eller vedligeholdelse af Windows-tjenester. Du kan bruge cloud-hostede VM'er som f.eks. Microsoft Dev Box, som tilbyder komplet Windows-virtualisering af arbejdsstationer med integration til software til administration af stationære computere. Alternativt kan lokale VM'er bruges med værktøjer som HashiCorp Vagrant- til administration af miljøer, og HashiCorp Packer kan anvendes til at bygge VM-billeder til både Vagrant og Dev Box.
For at målrette Linux passer arbejdsområdevirtualisering bedre med fokus på projektspecifikke eller programspecifikke miljøer i stedet for at erstatte et komplet skrivebord. Cloud-hostede objektbeholdere er et almindeligt valg med indstillinger som GitHub Codespaces, som indeholder et cloudbaseret Dev Container-miljø, der er kompatibelt med VS Code, JetBrains IntelliJ og terminalbaserede værktøjer. Hvis cloudindstillinger ikke opfylder dine behov, VS Code's SSH- eller fjerntunnel understøtter oprettelse af forbindelse til selv hostede Linux VM'er. Derudover er lokale objektbeholdere en mulighed, hvis du foretrækker at køre Udviklingsobjektbeholdere lokalt. VS Code- og IntelliJ- yde robust support til disse miljøer. For at opnå større fleksibilitet kan cloudbaserede VM'er, hvor du kan SSH direkte til selvadministrerede Linux VM'er, også bruges. I tilfælde, hvor udviklere udelukkende arbejder på Windows, tilbyder Windows Subsystem til Linux (WSL) en praktisk lokal Linux-udviklingsløsning. WSL-distributioner kan eksporteres og deles på tværs af teams. Cloudbaserede tjenester som Microsoft Dev Box også understøtte WSL til Linux-udvikling.
Brug af programskabeloner til ensartethed og standardisering
Organisationer kan bruge programskabeloner som en del af en "alt som kode"-tilgang for at fremme ensartethed, standardisering og bedste praksis på tværs af udviklingsteams. Disse skabeloner kan strømline udviklingen og sikre, at teams forbliver på de etablerede brolagte stier. For organisationer, der følger et monorepomønster, kan værktøjer som Azure Developer CLI (azd) bruges til at oprette skabeloner, der ikke kun omfatter konfigurationer af programkilder, men også miljøkonfigurationer og CI/CD-arbejdsprocesser.
Når du opretter skabeloner til udvikling, er det nyttigt at overveje forskellige nøgleområder for at sikre, at skabelonerne er omfattende og konsistente og overholder de bedste fremgangsmåder:
- Eksempel på kildekode: Medtag eksempelkildekode for at guide udviklere mod anbefalede sprog, programmodeller, tjenester, API'er, SDK'er og arkitektoniske mønstre.
- scripts til build og installation: Inkorporer scripts, der giver en ensartet måde at udløse builds og udrulle lokalt eller i et sandkassemiljø. Sørg for, at fejlfindingskonfigurationer i IDE eller editor er inkluderet for at synkronisere med CI/CD-pipelines.
- CI/CD-konfiguration: Angiv arbejdsprocesser eller pipelines til oprettelse og installation af programmer, der gør brug af genanvendelige, centraliserede arbejdsprocesser. Behandl disse som "start til højre"-skabeloner, og sørg for, at de giver mulighed for manuel udløsning, når det er nødvendigt.
- IaC-aktiver (Infrastructure as Code): Medtag anbefalede konfigurationer og referencer til centralt administrerede moduler for at sikre, at infrastrukturinstallationer følger bedste praksis.
- Sikkerhed og politik som kodeaktiver: Tilføj sikkerhedsrelaterede konfigurationsfiler, f.eks. CODEOWNERS og dependabot.yaml, for at inkorporere sikkerhed direkte i udviklingsprocessen. Planlagte arbejdsprocesser til sikkerhedsscanninger, herunder værktøjer som Microsoft Defender for Cloud, skal leveres for at integrere sikkerhed i CI/CD-pipelinen og forbedre sikkerheden i forsyningskæden.
- Observability, monitoring og logføring: Angiv konfigurationer til overvågningsværktøjer, f.eks. IaC til agentinstallation eller konfiguration som kode til overvågning af dashboards. Medtag eksempelkode til logføring og distribueret sporing for at sikre, at programmer kan overvåges effektivt, når de er installeret.
- konfiguration af kodemiljø: Tilføj konfigurationsfiler til linters, formattere og id'er, og konfigurer scripts til virtualiserede udviklingsmiljøer, f.eks. devcontainer.json, devbox.yaml eller Docker-relaterede filer.
- testkonfiguration: Angiv filer til enhedstest og mere omfattende testscenarier ved hjælp af værktøjer som Microsoft Playwright Testing eller Azure Load Testing.
konfiguration af samarbejdsværktøj: Medtag opgave-/problemskabeloner eller PR-skabeloner som kode, hvis det understøttes. Du kan også angive arbejdsprocesser, der bruger tilgængelige NØGLETAL eller API'er til at opdatere systemer eller konfigurere samarbejdsværktøjer som Microsoft Teams eller Slack.