Nalevings- en beveiligingsvalidaties voor pijplijnen - Sprint 141 Update

In juni van dit jaar hebben we de eerste iteratie van ons nieuwe navigatiemodel geïmplementeerd. We hebben de zomer besteed aan het verbeteren van die ervaring op basis van de feedback die velen van u hebben gegeven. Met vriendelijke groet, De volgende stap is om van het nieuwe model een preview-versie te maken en de navigatie voor het product te worden. Lees ons blogbericht waarin de recente wijzigingen worden beschreven, samen met onze planning voor het implementeren van het nieuwe model voor alle organisaties.

We begrijpen het belang van zoeken en brengen het uitgevouwen zoekvak terug in de productkoptekst. Bovendien kunt u nu het zoekvak aanroepen door op '/' te klikken op een servicepagina in Azure DevOps. Deze functie heeft prioriteit op basis van een suggestie van de gebruiker.

Dit is het standaardzoekvak:

Standaardzoekvak

Nadat u een '/' hebt getypt, ziet u het uitgevouwen zoekvak:

Uitgevouwen zoekvak

Azure Pipelines

Azure Policy nalevings- en beveiligingsvalidaties in pijplijnen

We willen de stabiliteit en beveiliging van software in een vroeg stadium van het ontwikkelingsproces garanderen en tegelijkertijd ontwikkeling, beveiliging en bewerkingen bij elkaar brengen. Hiervoor hebben we ondersteuning toegevoegd voor Azure Policy.

Azure Policy helpt u bij het beheren en voorkomen van IT-problemen met behulp van beleidsdefinities die regels en effecten voor uw resources afdwingen. Wanneer u Azure Policy gebruikt, blijven resources voldoen aan de standaarden en serviceovereenkomsten van uw bedrijf.

Om te voldoen aan de nalevings- en beveiligingsrichtlijnen als onderdeel van het releaseproces, hebben we onze implementatie-ervaring voor Azure-resourcegroepen verbeterd. Nu mislukken we de implementatietaak van de Azure-resourcegroep met relevante beleidsgerelateerde fouten in het geval van schendingen tijdens het implementeren van ARM-sjablonen.

Azure Policy

Daarnaast hebben we Azure Policy releasedefinitiesjabloon toegevoegd. Hierdoor kunnen gebruikers Azure-beleid maken en dit beleid toewijzen aan resources, abonnementen of beheergroepen vanuit de releasedefinitie zelf.

Azure Policy sjabloon

Vereenvoudigde continue levering aan Azure-VM's

In deze release hebben we een nieuwe wizard toegevoegd om het proces voor het instellen van continue levering naar Azure Virtual Machines te vereenvoudigen. Zodra u een Azure DevOps-organisatie en een implementatiegroep hebt opgegeven om de virtuele machine te registreren, wordt er automatisch een release-pijplijn gemaakt met een voorbeeldscriptstap. Als u extra Azure-resources wilt inrichten, scripts wilt uitvoeren, uw toepassing moet upgraden of aanvullende validatietests wilt uitvoeren, kunt u deze release-pijplijn eenvoudig aanpassen.

CI naar Azure-VM's

De Xcode-taak ondersteunt zojuist uitgebrachte Xcode 10

Samen met de release van Apple van Xcode 10 kunt u nu instellen dat uw projecten specifiek worden gebouwd of getest met Xcode 10. Uw pijplijn kan ook taken parallel uitvoeren met een matrix van Xcode-versies. U kunt de door Microsoft gehoste macOS-agentgroep gebruiken om deze builds uit te voeren. Zie de richtlijnen voor het gebruik van Xcode in Azure Pipelines.

Xcode 10

Prestatieverbeteringen bij het in de wachtrij plaatsen van een build

Wanneer u een gehoste agent gebruikt, krijgt u voor elke taak een nieuwe VM. Dit biedt een extra beveiligings- en controlelaag. U hoeft zich nooit zorgen te maken dat een eerdere build uitvoer verlaat of iets schadelijks doet voor de computer. De eerste opstartactiviteiten hielden eerder echter vertragingen in tussen het klikken op Een build in wachtrij plaatsen en het moment waarop de pijplijn daadwerkelijk wordt uitgevoerd. We hebben veel van deze vertragingen onderzocht en opgelost en zien nu een 5x-versnelling in wachtrij-naar-starttijd in de gehoste pools. U kunt nu sneller aan de slag met uw builds, wat betekent dat u sneller kunt herhalen.

Een Azure-serviceverbinding maken met een service-principal die wordt geverifieerd met een certificaat

U kunt nu een Azure-serviceverbinding definiëren in Azure Pipelines of Team Foundation Server (TFS) met een service-principal en certificaat voor verificatie. Nu de Azure-serviceverbinding de service-principal ondersteunt die wordt geverifieerd met een certificaat, kunt u nu implementeren in Azure Stack geconfigureerd met AD FS. Als u een service-principal met certificaatverificatie wilt maken, raadpleegt u het artikel over het maken van een service-principal die wordt geverifieerd met een certificaat.

Verbinding maken met service-principal

Testanalyses weergeven in Pijplijnen

Het bijhouden van de testkwaliteit in de loop van de tijd en het verbeteren van testmateriaal is essentieel voor het onderhouden van een goede pijplijn. De testanalysefunctie biedt bijna realtime inzicht in uw testgegevens voor builds en release-pijplijnen. Het helpt de efficiëntie van uw pijplijn te verbeteren door terugkerende problemen met hoge impactkwaliteit te identificeren.

U kunt testresultaten groeperen op verschillende elementen, belangrijke tests voor uw vertakking of testbestanden identificeren, of inzoomen op een specifieke test om trends te bekijken en inzicht te verkrijgen in kwaliteitsproblemen zoals flakiness.

Bekijk testanalyses voor builds en release, preview hieronder:

Testanalyses

Zie onze documentatie voor meer informatie.

Azure-opslagplaatsen

De doelbranch van een pull-aanvraag wijzigen

Voor de meeste teams zijn bijna alle pull-aanvragen gericht op dezelfde vertakking, zoals master of develop. In het geval dat u echter een andere vertakking wilt gebruiken, kunt u gemakkelijk vergeten om de standaardinstelling van de doelbranch te wijzigen. Met de nieuwe functie om de doelbranch van een actieve pull-aanvraag te wijzigen, is dit nu een eenvoudige actie. Klik op het potloodpictogram bij de naam van de doelbranch in de header van de pull-aanvraag.

Doelbranch wijzigen

Naast het corrigeren van fouten, maakt de functie voor het wijzigen van doelvertakkingen het ook eenvoudig om een pull-aanvraag te 'retargeten' wanneer de doelvertakking is samengevoegd of verwijderd. Overweeg een scenario waarin u een pull-aanvraag hebt die is gericht op een functiebranch die bepaalde functies bevat waarvan uw wijzigingen afhankelijk zijn. U wilt uw afhankelijke wijzigingen afzonderlijk bekijken van andere wijzigingen in de functiebranch, dus u richt features/new-featurezich in eerste instantie op . Revisoren kunnen vervolgens alleen uw wijzigingen zien en de juiste opmerkingen achterlaten.

Bedenk nu eens wat er zou gebeuren als de functiebranch ook een pull-aanvraag had en werd samengevoegd master vóór uw wijzigingen? Voorheen moest u uw wijzigingen afbreken en een nieuwe pull-aanvraag maken in master, of uw pull-aanvraag samenvoegen in features/new-featureen vervolgens een andere pull-aanvraag maken van features/new-feature tot master. Met deze nieuwe actie voor het bijwerken van de doelbranch kunt u eenvoudig de doelbranch van de pull wijzigen van features/new-feature in master, waarbij alle context en opmerkingen behouden blijven. Als u de doelbranch wijzigt, wordt er zelfs een nieuwe update voor de pull-aanvraag gemaakt, waardoor u eenvoudig terug kunt kijken naar eerdere verschillen vóór de wijziging van de doelbranch.

Update van doelbranch

Git-opslagplaatsen beveiligen met compatibiliteitsinstellingen voor meerdere platforms

Omdat Git een platformoverschrijdende technologie is, is het mogelijk dat bestanden of mappen hun weg vinden naar een bestandssysteem waar ze mogelijk niet compatibel zijn op een specifiek platform. Meer informatie over deze incompatibiliteit vindt u in onze documentatie.

Om teams te helpen hun opslagplaats en ontwikkelaars te beschermen, hebben we nieuwe opslagplaatsinstellingen toegevoegd om pushes te blokkeren die doorvoeringen bevatten met bestanden/mappen die niet compatibel zijn met een of meer besturingssysteemplatforms. Meer informatie over deze instellingen.

Beheer

AAD-gebruikers in MSA-accounts ondersteunen

Azure DevOps ondersteunt nu AzureAD-gebruikers (AAD) die toegang hebben tot organisaties die worden ondersteund door MSA. Voor beheerders betekent dit dat als uw Azure DevOps-organisatie MSA's voor zakelijke gebruikers gebruikt, u nu toegang kunt krijgen tot nieuwe werknemers met hun AAD-referenties in plaats van een nieuwe MSA-identiteit te maken die uitsluitend voor gebruik met Azure DevOps is bedoeld.

We zijn nog steeds van mening dat de beste ervaring is voor zakelijke gebruikers om Azure DevOps te verbinden met AAD, maar eerder dit jaar hebben we geleerd dat beheerders meer tijd nodig hadden om die conversie uit te voeren. Door AAD-gebruikers toe te staan in organisaties die door MSA worden ondersteund, hebben nieuwe gebruikers toegang tot Azure DevOps zodra Azure DevOps het maken van nieuwe MSA-gebruikers met aangepaste domeinnamen die aan het einde van de maand door AzureAD worden ondersteund, heeft voorkomen.

Voor organisaties die al gebruikmaken van AAD-identiteiten met Azure DevOps, is deze functie niet van toepassing. Voor organisaties die momenteel MSA-identiteiten gebruiken, moet u er rekening mee houden dat alle bestaande gebruikers zich kunnen blijven aanmelden met hun MSA-identiteiten zoals ze dat nu doen. Dit geldt alleen voor gebruikers die in de toekomst worden toegevoegd (die mogelijk geen MSA kunnen maken met hun zakelijke e-mailadres).

Hier volgt een voorbeeldscenario waarin deze ervaring nuttig kan zijn: Dorothy is de eigenaar van de Azure DevOps-organisatie voor haar bedrijf Fabrikam. Zij en haar team van tien teamleden melden zich allemaal aan bij Azure DevOps met MSA-identiteiten die gebruikmaken van hun zakelijke e-mailadres, bijvoorbeeld Dorothy@fabrikam.com. Sam is een nieuw teamlid dat vandaag bij het bedrijf is gekomen. Dorothy nodigt hem uit voor Azure DevOps met behulp van zijn e-mailadres, sam@fabrikam.com. Wanneer hij op de koppeling Nu deelnemen in de e-mail klikt, kan hij zich aanmelden bij Azure DevOps met dezelfde AAD-identiteit die hij heeft gekregen voor toegang tot zijn e-mail met Microsoft 365. Hierdoor kan Sam samenwerken met zijn 11 collega's en heeft Dorothy de vrijheid om haar Azure DevOps-organisatie te verbinden met AAD wanneer ze klaar is.

Zie ons blogbericht voor meer informatie.

Feedback geven

We horen graag wat u vindt van deze functies. Gebruik het feedbackmenu om een probleem te melden of een suggestie te doen.

Een suggestie doen

U kunt ook advies krijgen en uw vragen worden beantwoord door de community op Stack Overflow.

Met vriendelijke groet,

Gopinath Chigakkagari (Twitter)

Delen via