postupy DevOps pro LUIS

  • Článek
  • 11 min ke čtení

technici softwaru, kteří vyvíjí aplikaci Language Understanding (LUIS), mohou použít DevOps postupy týkající se správy zdrojového kódu, automatizované sestavení, testovánía správy vydaných verzí pomocí následujících pokynů.

Správa zdrojového kódu a strategie větvení pro LUIS

jeden z klíčových faktorů, na kterých úspěšnost DevOps závisí na správě zdrojového kódu. Systém správy zdrojového kódu umožňuje vývojářům spolupracovat na kódu a sledovat změny. Použití větví umožňuje vývojářům přepínat mezi různými verzemi základu kódu a pracovat nezávisle na jiných členech týmu. Když vývojáři vyvolají žádost o přijetí změn (PR), aby navrhli aktualizace z jedné větve do druhé nebo když jsou změny sloučeny, mohou být triggerem pro automatizované sestavení pro sestavení a průběžný testování kódu.

Pomocí konceptů a návodů, které jsou popsány v tomto dokumentu, můžete vyvíjet aplikaci LUIS při sledování změn v systému správy zdrojů a postupovat podle osvědčených postupů pro Software Engineering:

  • Správa zdrojového kódu

    • Zdrojový kód aplikace pro LUIS je ve formátu čitelném pro člověka.
    • Model může být sestavený ze zdroje způsobem, který lze opakovaně vytvořit.
    • Zdrojový kód lze spravovat pomocí úložiště zdrojového kódu.
    • Přihlašovací údaje a tajné klíče, jako jsou vytváření a klíče předplatného, se ve zdrojovém kódu nikdy neukládají.

  • Větvení a slučování

    • Vývojáři mohou pracovat z nezávislých větví.
    • Vývojáři mohou současně pracovat v několika větvích.
    • Je možné integrovat změny do aplikace LUIS z jedné větve do jiné prostřednictvím přenesení změn nebo sloučení.
    • Vývojáři mohou sloučit žádosti o přijetí změn s nadřazenou větví.

  • Správa verzí

    • Jednotlivé komponenty ve velkých aplikacích by měly být nezávislé na verzi a umožňují vývojářům detekovat zásadní změny nebo aktualizace pouhým vyhledáním čísla verze.

  • Revize kódu

    • Změny v žádosti o přijetí změn se zobrazí jako zdrojový kód pro čtení, který je možné před přijetím žádosti o přijetí změn zkontrolovat.

Správa zdrojového kódu

Chcete-li zachovat definici schématu aplikace aplikace Luis v systému správy zdrojového kódu, použijte reprezentaci aplikace LUDown Format ( .lu ) . .lu formát je preferovaný .json , protože je čitelný pro člověka, což usnadňuje provádění a kontrolu změn v pr.

Uložení aplikace LUIS pomocí formátu LUDown

Pokud chcete uložit aplikaci LUIS ve .lu formátu a umístit ji pod správu zdrojového kódu:

  • BUĎ: exportujte verzi aplikace .lu z portálu Luis a přidejte ji do úložiště správy zdrojového kódu.

  • NEBO: pomocí textového editoru vytvořte .lu soubor pro aplikaci Luis a přidejte ji do úložiště správy zdrojového kódu.

Tip

Pokud pracujete s exportem JSON aplikace LUIS, můžete ji převést na LUDown. Tuto --sort možnost použijte, chcete-li zajistit, aby byly záměry a projevy seřazené abecedně.
Všimněte si, že . Funkce exportu logické jednotky , která je součástí portálu Luis, již seřadí výstup.

Sestavení aplikace LUIS ze zdroje

Pro aplikaci LUIS, která se má vytvořit ze zdrojové verze, vytvoří novou verzi aplikace Luis importováním .lu zdroje , vyškolí verzi a publikuje ji. Můžete to provést na portálu LUIS nebo na příkazovém řádku:

Soubory, které se mají spravovat pod správou zdrojových kódů

V rámci správy zdrojového kódu by měly být zachovány následující typy souborů pro aplikaci LUIS:

Přihlašovací údaje a klíče nejsou vráceny se změnami.

Nezahrnujte klíče předplatného ani podobné důvěrné hodnoty do souborů, které jste se změnami navrátit do úložiště, kde můžou být viditelné pro neoprávněné zaměstnance. Mezi klíče a další hodnoty, které byste měli zabránit vrácení se změnami, patří:

  • LUIS vytváření a předpověď klíčů
  • Koncové body vytváření a předpovědi LUIS
  • Klíče předplatného Azure
  • Přístupové tokeny, jako je token pro instanční objekt Azure, který se používá pro ověřování služby Automation

Strategie pro bezpečnou správu tajných kódů

Mezi strategie pro bezpečnou správu tajných klíčů patří:

  • Pokud používáte správu verzí Gitu, můžete ukládat tajné klíče za běhu do místního souboru a zabránit vrácení souboru se změnami, a to přidáním vzoru, který bude odpovídat názvu souboru . gitignore.
  • V pracovním postupu automatizace můžete tajné kódy bezpečně ukládat do konfigurace parametrů, kterou nabízí tato technologie automatizace. pokud například používáte akce GitHub, můžete tajné klíče bezpečně ukládat v GitHub tajných klíčích.

Větvení a slučování

Distribuované systémy správy verzí, jako je git, poskytují flexibilitu v tom, jak členové týmu publikují, sdílejí, kontrolují a iterují změny kódu prostřednictvím větví vývoje sdílených s ostatními. Proveďte strategii větvení Git , která je vhodná pro váš tým.

Jakékoli strategie větvení, kterou přijmete, je klíčovým principem všech z nich, že členové týmu mohou pracovat na řešení v rámci větve funkcí nezávisle na práci, která se nachází v jiných větvích.

Podpora nezávislého fungování v větvích s projektem LUIS:

  • Hlavní větev má svou vlastní aplikaci pro LUIS. Tato aplikace představuje aktuální stav vašeho řešení pro váš projekt a jeho aktuální aktivní verze by měla být vždy namapována na .lu zdroj, který je v hlavní větvi. Všechny aktualizace .lu zdroje pro tuto aplikaci by měly být přezkoumány a testovány, aby bylo možné tuto aplikaci nasadit do prostředí pro vytváření prostředí, jako je například výroba. Když .lu se aktualizace sloučí do hlavní větve z nějaké funkce, měli byste v aplikaci Luis vytvořit novou verzi a přeložit číslo verze.

  • Každá větev funkce musí používat svou vlastní instanci aplikace Luis. Vývojáři pracují s touto aplikací ve větvi funkcí bez rizika ovlivnění vývojářů, kteří pracují v jiných větvích. Tato aplikace pro vývojovou větev je pracovní kopie, která se má odstranit při odstranění větve funkce.

Větev funkcí Git

Vývojáři můžou pracovat z nezávislých větví

Vývojáři můžou pracovat na aktualizacích aplikace v LUIS nezávisle na jiných větvích:

  1. Vytvoření větve funkce z hlavní větve (v závislosti na strategii vaší větve, obvykle hlavní nebo vyvíjené).

  2. Vytvořte novou aplikaci Luis na portálu Luis (aplikace pro vývojovou větev), která podporuje výhradně práci ve větvi funkce.

    • Pokud .lu zdroj vašeho řešení již existuje ve větvi, protože byl uložen po dokončení práce v jiné větvi dříve v projektu, vytvořte Luis aplikaci pro vývojovou větev pomocí importu .lu souboru.

    • Pokud spouštíte práci na novém projektu, zatím nebudete mít .lu zdroj vaší hlavní aplikace pro Luis v úložišti. Soubor vytvoříte tak, .lu že svou aplikaci pro vývojovou větev vyexportujete z portálu, když jste dokončili práci ve větvi vaší funkce, a odešlete ji jako součást vaší žádosti o přijetí změn.

  3. K implementaci požadovaných změn Pracujte na aktivní verzi aplikace pro vývojovou větev. Doporučujeme pracovat pouze v jediné verzi aplikace pro vývojovou větev pro veškerou funkci práce s větví. Pokud vytvoříte více než jednu verzi v aplikaci pro vývojovou větev, buďte opatrní, abyste sledovali, která verze obsahuje změny, které chcete vrátit se změnami při vyvolání žádosti o přijetí změn.

  4. testování aktualizací – podrobnosti o testování aplikace pro vývojovou větev najdete v tématu testování pro LUIS DevOps .

  5. Exportujte aktivní verzi aplikace pro vývojovou větev .lu ze seznamu verzí.

  6. Zaregistrujte aktualizace a pozvěte druhou kontrolu vašich aktualizací. pokud používáte GitHub, vyvoláte žádost opřijetí změn.

  7. Po schválení změn sloučíte aktualizace do hlavní větve. V tuto chvíli vytvoříte novou verzi hlavní aplikace Luis pomocí aktualizovaného .lu v části Main. Pokyny k nastavení názvu verze najdete v tématu Správa verzí .

  8. Když je větev funkce odstraněna, je vhodné odstranit aplikaci pro vývojovou větev LUIS, kterou jste vytvořili pro funkci pracovní větve.

Vývojáři mohou současně pracovat v několika větvích.

Pokud budete postupovat podle vzoru popsaného výše v tématu vývojáři můžou pracovat z nezávislých větví, pak v každé větvi funkce použijete jedinečnou aplikaci Luis. Jeden vývojář může pracovat souběžně s několika větvemi, pokud se přepne do správné aplikace LUIS pro vývojovou větev pro větev, na které aktuálně pracují.

Doporučujeme použít stejný název pro větev funkcí i pro aplikaci LUIS pro vývojovou větev, kterou vytvoříte pro práci ve větvi funkce, aby bylo méně pravděpodobný, že nebudete muset omylně fungovat na nesprávné aplikaci.

Jak je uvedeno výše, doporučujeme, abyste pro zjednodušení pracovali v jedné verzi v každé aplikaci pro vývoj bran. Pokud používáte víc verzí, při přepínání mezi aplikacemi pro vývojovou větev se ujistěte, že jste si aktivovali správnou verzi.

Současně může ve stejné větvi fungovat více vývojářů

Současně můžete podporovat více vývojářů pracujících na stejné větvi funkcí:

  • Vývojáři si můžou zaregistrovat stejnou větev funkcí a nabízené změny a žádosti o přijetí změn, které odeslali sami a další vývojáři, zatímco fungují normálně.

  • Pokud budete postupovat podle vzoru popsaného výše v tématu vývojáři můžou pracovat z nezávislých větví, pak tato větev bude k podpoře vývoje používat jedinečnou aplikaci Luis. Tato aplikace LUIS pro vývojovou větev bude vytvořena prvním členem vývojového týmu, který začíná pracovat ve větvi funkce.

  • Přidejte členy týmu jako přispěvatele do aplikace dev Branch Luis.

  • Když je dokončená větev funkcí, exportujte aktivní verzi aplikace dev Work LUIS jako .lu v seznamu verze, uložte aktualizovaný .lu soubor do úložiště a vraťte se změnami a přičtěte změny.

Zahrnutí změn z jedné větve do druhé se přenesením změn nebo sloučením

Někteří vývojáři v týmu, kteří pracují v jiné větvi, mohli ve svém týmu aktualizovat .lu zdroj a sloučit je do hlavní větve po vytvoření vaší větve funkce. Před tím, než budete moci provádět vlastní změny v rámci větve funkcí, můžete chtít své změny začlenit do své pracovní verze. To můžete provést přenesením změn nebo sloučením do Main stejným způsobem jako jakýkoli jiný prostředek kódu. Vzhledem k tomu, že aplikace LUIS ve formátu LUDown je humánní čitelnost, podporuje sloučení pomocí standardních nástrojů pro sloučení.

Pokud vaše aplikace LUIS přenášíte do větve funkcí, postupujte podle těchto tipů:

  • Před přenesením nebo sloučením se ujistěte, že vaše místní kopie .lu zdrojového kódu vaší aplikace obsahuje všechny nejnovější změny, které jste použili na portálu Luis, a to tak, že aplikaci znovu exportujete z portálu. Tímto způsobem se můžete ujistit, že jakékoli změny, které jste provedli na portálu a ještě nejsou exportovány, nebudou ztraceny.

  • Během sloučení můžete vyřešit všechny konflikty sloučení pomocí standardních nástrojů.

  • Nezapomeňte po přenesení změn nebo sloučení dokončit, aby se znovu naimportovala aplikace zpátky na portál, takže budete pracovat s aktualizovanou aplikací, protože budete dál používat vlastní změny.

Sloučit PR

Po schválení žádosti o přijetí změn můžete sloučit změny do vaší hlavní větve. Na zdroj LUDown pro aplikaci LUIS se nevztahují žádné zvláštní požadavky: Jedná se o lidské čtení a podporuje slučování pomocí standardních nástrojů pro sloučení. Jakékoli konflikty sloučení lze vyřešit stejným způsobem jako u jiných zdrojových souborů.

Po sloučení žádosti o přijetí změn se doporučuje vyčistit:

  • Odstranění větve ve vašem úložišti

  • Odstraňte aplikaci LUIS pro vývojovou větev, kterou jste vytvořili pro práci ve větvi funkce.

Stejným způsobem jako u prostředků kódu aplikace byste měli napsat testy jednotek, které doprovázejí aktualizace aplikací LUIS. Měli byste využít pracovní postupy průběžné integrace k testování:

  • Aktualizace v žádosti o přijetí změn před sloučením žádosti o přijetí změn
  • Hlavní aplikace LUIS po schválení žádosti o přijetí změn a změny byly sloučeny do hlavní větve.

další informace o testování LUIS DevOps najdete v tématu testování pro DevOps pro LUIS. Další podrobnosti o implementaci pracovních postupů najdete v tématu pracovní postupy automatizace pro LUIS DevOps.

Revize kódu

Aplikace LUIS ve formátu LUDown je humánní čitelnost, která podporuje komunikaci se změnami v žádosti o přijetí změn, která je vhodná ke kontrole. Soubory testování částí jsou také zapsány ve formátu LUDown a lze je snadno zobrazit v žádosti o přijetí změn.

Správa verzí

Aplikace se skládá z několika komponent, které můžou zahrnovat věci, jako je robot běžící v Azure bot Service, QnA maker, Služba Azure Speech Servicea další. Aby bylo možné dosáhnout cíle volně vázaných aplikací, použijte řízení verze tak, aby každá komponenta aplikace byla oddělená od verze, a umožní vývojářům detekovat zásadní změny nebo aktualizace pouze tím, že si prohlíží číslo verze. Aplikaci LUIS je snazší používat nezávisle na jiných součástech, pokud ji udržujete ve vlastním úložišti.

Aplikace LUIS pro hlavní větev by měla mít použité schéma správy verzí. Když sloučíte aktualizace do .lu aplikace Luis do Main, naimportujete aktualizovaný zdroj do nové verze v aplikaci Luis pro hlavní větev.

Doporučujeme, abyste pro hlavní verzi aplikace LUIS používali schéma numerických verzí, například:

major.minor[.build[.revision]]

Každá aktualizace číslo verze se zvýší na poslední číslici.

Hlavní a vedlejší verzi lze použít k označení rozsahu změn funkce aplikace LUIS:

  • Hlavní verze: významná změna, například podpora pro nový záměr nebo entitu
  • Podverze: zpětně kompatibilní menší změny, například po významném novém školení
  • Sestavení: žádné změny funkčnosti, pouze jiné sestavení.

Jakmile určíte číslo verze pro nejnovější revizi hlavní aplikace LUIS, je potřeba sestavit a otestovat novou verzi aplikace a publikovat ji na koncový bod, kde se dá použít v různých prostředích buildu, jako je například zabezpečování kvality nebo produkce. V pracovním postupu průběžná integrace (CI) se důrazně doporučuje automatizovat všechny tyto kroky.

Přečtěte si:

Správa verzí aplikace LUIS pro větev funkcí

Když pracujete s aplikací LUIS vývojová větev, kterou jste vytvořili pro podporu práce ve větvi funkce, budete aplikaci exportovat po dokončení práce a v žádosti o přijetí změn zahrnete aktualizovaný 'lu . Větev v úložišti a aplikace LUIS pro vývojovou větev by se měla po sloučení žádosti o přijetí změn na Main odstranit. Vzhledem k tomu, že tato aplikace existuje výhradně pro podporu práce ve větvi funkce, neexistuje žádné konkrétní schéma správy verzí, které by bylo potřeba v této aplikaci použít.

Když se změny v žádosti o přijetí změn sloučí do hlavní, to znamená, že se má použít Správa verzí, aby se všechny aktualizace Main používaly nezávisle.

Další kroky