Integreren met ServiceNow-wijzigingsbeheer
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Azure Pipelines biedt ondersteuning voor integratie met ServiceNow om de samenwerking tussen ontwikkelings- en IT-teams te verbeteren. Door wijzigingsbeheer in releasepijplijnen op te nemen, kunnen teams de risico's verminderen die zijn gekoppeld aan wijzigingen en servicebeheermethoden volgen, zoals ITIL, terwijl ze optimaal profiteren van Azure Pipelines.
In dit artikel leert u het volgende:
- ServiceNow-exemplaren configureren.
- Neem het ServiceNow-wijzigingsbeheerproces op als een releasepoort.
- Bewaak het wijzigingsbeheerproces van releasepijplijnen.
- Houd ServiceNow-wijzigingsaanvragen bijgewerkt met implementatieresultaten.
Vereisten
In deze zelfstudie wordt het gebruik van goedkeuringen en poorten uitgebreid en worden goedkeuringen en controles gedefinieerd.
een Azure DevOps-organisatie. Maak een organisatie als u er nog geen hebt.
Een niet-ontwikkelaarexemplaren van ServiceNow.
Het ServiceNow-exemplaar configureren
Installeer de Azure Pipelines-extensie op uw ServiceNow-exemplaar. U hebt Hi-referenties nodig om de installatie te voltooien. Zie Aankoopoverzicht voor meer informatie over het installeren van apps vanuit de ServiceNow Store.
Maak een nieuwe gebruiker in ServiceNow en geef deze de volgende rol:
x_mioms_azpipeline.pipelinesExecution
.
De Azure DevOps-organisatie instellen
Installeer de ServiceNow Change Management-extensie in uw Azure DevOps-organisatie.
Maak als volgt een nieuwe ServiceNow-serviceverbinding in uw Azure DevOps-project. U kunt ook OAuth2-verificatie gebruiken.
De release-pijplijn configureren
Navigeer naar uw release-pijplijn en selecteer vervolgens het pictogram voorwaarden vóór de implementatie. Selecteer Gates en de serviceNow Change Management-poort vóór de implementatie.
Selecteer de serviceverbinding die u eerder hebt gemaakt en vul de vereiste velden als volgt in:
- ServiceNow-verbinding: Verbinding maken ion naar het ServiceNow-exemplaar dat wordt gebruikt voor wijzigingsbeheer.
- Korte beschrijving: Een samenvatting van de wijziging.
- Beschrijving: Een gedetailleerde beschrijving van de wijziging.
- Categorie: De categorie van de wijziging. Voorbeeld: Hardware, Netwerk, Software.
- Prioriteit: Prioriteit van de wijziging.
- Risico: het risiconiveau voor de wijziging.
- Impact: Het effect dat de wijziging op het bedrijf heeft.
- Configuratie-item: Configuratie-item (CI) waarop de wijziging van toepassing is.
- Toewijzingsgroep: de groep waaraan de wijziging is toegewezen.
- Planning van wijzigingsaanvraag: Planning van de wijziging zoals gehonoreerd door de ServiceNow-werkstroom. Datum en tijd moeten in UTC zijn en de notatie jjjj-MM-ddTHH:mm:ssZ. Voorbeeld: 2018-01-31T07:56:59Z.
- Aanvullende parameters voor wijzigingsaanvragen: De naam moet een veldnaam (geen label) met het voorvoegsel 'u_' zijn. Voorbeeld: u_backout_plan. De waarde moet een geldige waarde zijn in ServiceNow. Ongeldige vermeldingen worden genegeerd.
- Gewenste status van wijzigingsaanvraag: de poort zou slagen en de pijplijn wordt voortgezet wanneer de status van de wijzigingsaanvraag hetzelfde is als de opgegeven waarde.
- Geavanceerd: Hiermee geeft u een expressie op die bepaalt wanneer deze poort moet slagen. De wijzigingsaanvraag wordt gedefinieerd als root['result'] in het antwoord van ServiceNow. Voorbeeld: "and(eq(root['result'].state, 'New'),eq(root['result'].risk, 'Low'))'. Zie Expressies voor meer informatie.
- Uitvoervariabelen: u moet een verwijzingsnaam opgeven om uitvoervariabelen in uw implementatiewerkstroom te kunnen gebruiken. Poortvariabelen kunnen worden geopend met 'PREDEPLOYGATE' als een voorvoegsel in een taak zonder agent. Wanneer de verwijzingsnaam bijvoorbeeld is ingesteld op 'gate1', kan het wijzigingsnummer als volgt worden verkregen: $(PREDEPLOYGATE.gate1.CHANGE_REQUEST_NUMBER).
- CHANGE_REQUEST_NUMBER: het nummer van de wijzigingsaanvraag.
- CHANGE_SYSTEM_ID: systeem-id van de wijzigingsaanvraag.
Voeg aan het einde van uw release-pijplijn een taak zonder agent toe met een taak Update ServiceNow Change Request.
- ServiceNow-verbinding: Verbinding maken ion naar het ServiceNow-exemplaar dat wordt gebruikt voor wijzigingsbeheer.
- Wijzigingsaanvraagnummer: Nummer van de wijzigingsaanvraag die moet worden bijgewerkt.
- Bijgewerkte status van wijzigingsaanvraag : Status die moet worden ingesteld voor de wijzigingsaanvraag. Deze invoer is beschikbaar als de updatestatus is geselecteerd.
- Sluit code en notities sluiten: Retourstatus.
Notitie
De taak Update ServiceNow-wijzigingsaanvraag mislukt als geen van de velden van de wijzigingsaanvraag wordt bijgewerkt tijdens de uitvoering. ServiceNow negeert ongeldige velden en waarden die aan de taak zijn doorgegeven.
Een release-pijplijn maken
Selecteer Release maken om een nieuwe release-pijplijn te starten.
Uw pijplijn moet een nieuwe wijzigingsaanvraag maken in ServiceNow als onderdeel van de voorwaarden vóór de implementatie die u eerder hebt gemaakt.
De pijplijn wacht totdat alle poorten binnen hetzelfde steekproefinterval zijn geslaagd. Als u het wijzigingsnummer wilt controleren, selecteert u het statuspictogram om uw pijplijnlogboeken weer te geven.
De wijzigingsaanvraag wordt in de wachtrij geplaatst in ServiceNow en kan worden bekeken door de eigenaar van de wijziging.
De release-pijplijn die de nieuwe wijzigingsaanvraag heeft geactiveerd, vindt u in de sectie Metagegevens van de Azure DevOps-pijplijn.
Wanneer de wijziging gereed is voor implementatie (verplaatst naar de status Implementeren), wordt de uitvoering hervat en moet de status van de poort zijn geretourneerd.
De wijzigingsaanvraag wordt na de implementatie automatisch gesloten.
Yaml-pijplijnen
In deze zelfstudie wordt ervan uitgegaan dat u een yaml-pijplijn hebt met één fase die wordt geïmplementeerd in een 'nieuwste' omgeving.
Een controle toevoegen
Navigeer naar uw omgeving 'nieuwste', selecteer de knop met het beletselteken en selecteer vervolgens Goedkeuringen en controles.
Selecteer het plusteken om een nieuwe controle toe te voegen en voeg vervolgens de controle van ServiceNow Change Management toe aan uw omgeving. Gebruik dezelfde configuratie die u hebt gebruikt voor uw pre-implementatiepoort.
De yaml-taak toevoegen
Voeg een servertaak toe aan uw fase om de wijzigingsaanvraag bij te werken.
Sla uw pijplijn op en voer deze uit. Er wordt automatisch een nieuwe wijzigingsaanvraag gemaakt en de pijplijn wordt onderbroken en wacht tot de controles zijn voltooid.
Zodra de controles zijn voltooid, moet de pijplijn de uitvoering hervatten. De wijzigingsaanvraag wordt na de implementatie automatisch gesloten.
Veelgestelde vragen
V: Welke versies van ServiceNow worden ondersteund?
A: We ondersteunen de volgende versies: Kingston, Londen, New York, Parijs, Quebec, Rome, San Diego en Tokio.
A: We ondersteunen de volgende versies: Kingston, Londen, New York, Parijs en Quebec.
A: We ondersteunen de volgende versies: San Diego, Tokio en Utah releases.
V: Welke typen wijzigingsaanvragen worden ondersteund?
A: Normale, standaard- en noodwijzigingsaanvragen worden ondersteund met deze integratie.
V: Hoe kan ik extra wijzigingseigenschappen instellen?
A: U kunt aanvullende wijzigingseigenschappen opgeven in het veld Aanvullende wijzigingsaanvraagparameters . Gebruik een JSON-indeling voor sleutel-waardeparen, waarbij de naam de veldnaam is (niet het label) met het voorvoegsel u_
.
V: Kan ik aangepaste velden in de wijzigingsaanvraag bijwerken met aanvullende parameters voor wijzigingsaanvragen?
A: Als aangepaste velden zijn gedefinieerd in de wijzigingsaanvraag, moet u toewijzing toevoegen voor aangepaste velden in de transformatietoewijzing importset.
V: Ik zie geen vervolgkeuzelijstwaarden ingevuld voor de velden Categorie, Status en andere velden. Wat moet ik doen?
A: Change Management Core en Change Management - State Model plugins moeten actief zijn op uw ServiceNow-exemplaar om de vervolgkeuzelijsten te laten werken. Zie Statussen voor upgradewijzigingsbeheer en Wijzigingsaanvraag bijwerken voor meer informatie.
Resources
- Uw release-pijplijnen configureren voor veilige implementaties
- Twitter-gevoel als releasepoort
- GitHub-problemen als releasepoort
- Aangepaste poorten maken.
- Voorbeeld van ServerTaskHelper-bibliotheek