Delad källkod
Utgå från en gemensam Git-källkod och bevara exakt commit och den användarvänliga version som hör till en release. Olika distributionstyper kan utvecklas oberoende samtidigt som de förblir kopplade till samma källkodshistorik.
Programvaruleverans
Från delad källkod till en kontrollerad installation.
Microwave Pies funktioner för programvaruleverans är utformade för att göra implementering av självhostade applikationer enklare: hantera releaser från delad källkod, skapa rätt paket för en installation, tillämpa licensiering och håll installation och uppdateringar kopplade till en känd release.
Delad leveransmodell
1Delad applikationskällkodEn källkodshistorik och en releaseidentitet.
2PlattformsreleaseBygg för den avsedda distributionsmiljön.
Källkodspaket
Kompilerat paket
3Licensierat paketUtfärda paketet för en specifik implementering.
4Installera och uppdateraHåll distributionshistoriken kopplad till den release som levererades.
Funktioner
Håll releasevalen flexibla utan att förlora kontrollen.
Olika miljöer behöver inte alltid samma paketformat eller samma release samtidigt. Microwave Pie skiljer delad applikationskällkod, återanvändbara releaser, paket, licenser och installerade instanser så att varje del kan utvecklas kontrollerat.
Källkodspaket
Leverera applikationen som källkod när transparens, direkt distribution i körmiljön eller plattformsspecifik Python-installation passar bäst. Källkodspaket använder samma release- och licensmodell som kompilerade paket.
Kompilerade paket
Leverera ett kompilerat applikationspaket när en mer självständig körmiljö föredras. Kompilering är ett leveransval, inte en separat produktlinje, så releaseursprunget förblir konsekvent.
Paket- och licenshantering
Utfärda ett paket där licensen och målmiljön för installationen redan är kopplade. Paketets livscykel, licensstatus, nedladdningar, installationer, uppdateringar, återkallelse och avslut kan hanteras tillsammans i stället för att rekonstrueras senare.
Målspecifika releaseval
Raspberry Pi-, GCP-, källkods- och kompilerade distributionstyper kan ligga på olika releasenivåer när det finns skäl till det. Saknade Git-commits kan granskas per distributionstyp och över hela applikationen.
Uppdateringar som hanteras i gränssnittet
Hanterade applikationer kan automatiskt visa när en godkänd uppdatering finns tillgänglig utan att tvinga fram den. En administratör väljer när uppdateringen ska förberedas och tillämpas i applikationens gränssnitt; efter omstart kan den installerade releasen bekräftas tillbaka till den delade leveranstjänsten samtidigt som relationen mellan Paket och Licens bevaras.
Implementering
Paketera distributionen, inte osäkerheten.
Ett programvarupaket kan bära den implementeringskontext som behövs för att göra en applikationsrelease till en fungerande distribution: målplattform, paketformat, installationsbeteende, releaseidentitet och licensrelation.
Då kan implementeringsprocessen börja från en känd release i stället för att varje miljö självständigt återskapar bygg- och leveransbeslut. När en nyare release är lämplig kan den befintliga relationen mellan Paket och Licens förbli intakt medan den valda releasen flyttas fram kontrollerat.
Applikationsreleaser bevarar artefakten och Git-identiteten som faktiskt byggdes.
Tillgänglighet kan meddelas automatiskt, men nedladdning, förberedelse, tillämpning och omstart förblir medvetna administratörsåtgärder.
Paket, licenser och installerade instanser förblir kopplade genom installation, uppdatering, återkallelse och avslut.
Blackcap
En applikation använder modellen i dag.
Blackcap kan distribueras till stödda Raspberry Pi- och GCP-miljöer med källkodspaket eller kompilerade paket samtidigt som beteendet för release, paket, licens och uppdatering hålls samordnat.