Steps Manipulation Tool: flytta plug-in-steg till en ny version av en assembly
Ett assemblyversionsnummer består av major.minor.build.revision. Vi använder nummer som 9.1.2610.1004, men regeln är densamma hur ni än numrerar. Så länge bara build eller revision ändras (9.1.2610.1004 → 9.1.2611.1020) uppdaterar du assemblyn på plats och alla steg fortsätter att fungera. Ändrar du major- eller minor-versionen (9.1 → 9.2, eller 10.0) är det en annan sak: Dataverse ser en annan assembly, så den nya versionen registreras bredvid den gamla, med egna plug-in-typer. Alla befintliga steg pekar fortfarande på den gamla versionen.
Det är när de ska över till 2.0 som huvudvärken börjar.
Det traditionella sättet, och varför det gör ont
Det vanliga är att skapa om varje steg på de nya plug-in-typerna och radera de gamla:
- Varje steg sätts upp igen för hand: meddelande, tabell, filterattribut, steg i pipelinen, läge, körordning, pre- och post-images, säker och osäker konfiguration. Med tiotals steg är det lätt att missa eller skriva fel.
- Varje omskapat steg får ett nytt GUID. För Dataverse är det en helt ny komponent, inte det gamla steget som flyttats.
- Sedan kommer ALM. Lösningen innehåller nu nya steg, men test och produktion har fortfarande de gamla igång på den gamla versionen. Importen lägger till de nya stegen bredvid. Om ingen tar bort de gamla stegen i varje miljö vid rätt tillfälle körs samma logik två gånger, eller inte alls under övergången.
Vad Steps Manipulation Tool gör
Steps Manipulation Tool för XrmToolBox flyttar de befintliga stegen till plug-in-typerna i den nya assemblyn genom att uppdatera varje stegpost. Det enda som ändras är vilken plug-in-typ steget pekar på. Ingenting raderas eller skapas om:
| Omskapat på den nya versionen | Flyttat med verktyget | |
|---|---|---|
| Stegets GUID | Nytt | Samma |
| Meddelande, tabell, filterattribut | Fylls i igen | Behålls |
| Steg i pipelinen, läge, körordning | Fylls i igen | Behålls |
| Pre- och post-images | Skapas om | Behålls |
| Säker och osäker konfiguration | Fylls i igen | Behålls |
| I lösningen | En ny komponent; den gamla måste tas bort överallt | Samma komponent, som nu pekar på den nya versionen |
Så tar sig uppgraderingen genom era miljöer
Eftersom stegen behåller sina GUID följer ändringen med lösningen som vilken uppdatering som helst:
- Utveckling: registrera den nya versionen av assemblyn. Den hamnar bredvid den gamla versionen.
- Utveckling: öppna Steps Manipulation Tool och flytta stegen från de gamla plug-in-typerna till motsvarande typer i den nya assemblyn.
- Lösning: se till att den nya assemblyn finns i lösningen. Stegen finns redan där, eftersom de är samma komponenter som tidigare.
- Test och produktion: importera lösningen som vanligt. Dataverse känner igen varje steg på dess GUID och uppdaterar det så att det pekar på den nya assemblyn. Stegen flyttar automatiskt till den nya versionen, utan manuellt arbete i målmiljön.
- Städa när det passar: den gamla assemblyn finns kvar i test och produktion efter importen, liksom eventuella steg där som inte kommer från er utvecklingslösning; de fortsätter att köras på den gamla versionen, orörda. Administratörer kan flytta eller avveckla de stegen och ta bort den gamla assemblyn när de är redo.
Resultatet: en ny assemblyversion blir en vanlig driftsättning i stället för en manuell och felbenägen övergång i varje miljö.
Så använder du verktyget
- Öppna Steps Manipulation Tool i XrmToolBox och anslut till utvecklingsmiljön.
- Välj Source Assembly (den gamla versionen) och Source Plugin, eller All types, för att lista stegen.
- Markera stegen som ska flyttas. Använd Ctrl eller Skift för flera, eller högerklicka → Select All.
- Under Destination väljer du Target Assembly (den nya versionen) och Target Plugin, klassen som nu hanterar stegen.
- Klicka på Move Selected Steps. Listan läses in på nytt från miljön när flytten är klar.
Upprepa för varje plug-in-typ tills den gamla assemblyn inte har några steg kvar.
Spara ett före och efter. Högerklicka på de markerade stegen → Export Selected sparar en reference-snapshot.xml med varje plug-in-typ, dess steg, deras meddelandefilter, läge, steg i pipelinen och status samt deras images. Exportera före och efter flytten och jämför; det enda som ska skilja är plug-in-typen.
Användbart även när…
Samma flytt hjälper vid andra refaktoreringar: när en stor assembly delas upp i mindre, när klasser eller namnområden byter namn (vilket registrerar nya plug-in-typer) eller när två plug-ins slås ihop till en. I alla fallen kan stegen följa koden utan att skapas om.
Använd det med eftertanke
Verktyget skriver direkt i metadata för plug-in-steg. Behandla det som vilken annan ändring av produktionslogik som helst:
- Exportera först en lösning med berörda assemblies och steg, som säkerhetskopia.
- Gör flytten i utvecklingsmiljön, kontrollera den där och för den vidare med er vanliga ALM-process.
- Säkerställ att varje målklass verkligen hanterar meddelandet som stegen är registrerade för. Verktyget flyttar stegen; det kontrollerar inte din kod.
- Kontrollera efteråt att stegen körs som väntat, att images och filterattribut är intakta och att inga dubbletter finns.
- Testa lösningsimporten i en testmiljö innan produktion, särskilt med hanterade lösningar och flera lösningslager.
Hämta det
- XrmToolBox: Tool Library → sök efter Steps Manipulation Tool → Install.
- NuGet: ImranAkram.XTB.StepManipulationTool
- Källkod (MIT): imranakram/StepsManipulationTool
Steps Manipulation Tool utvecklas och underhålls av Imran Akram på Biznamics, på hans GitHub, där nya versioner byggs och publiceras. Den första versionen skapades av Olekssi Shytikov. Issues och pull requests är välkomna på GitHub; ange din XrmToolBox-version och hur felet kan återskapas.