Fælles kildekode
Start fra en fælles Git-kilde, og bevar det præcise commit og den brugervenlige version, der er knyttet til en udgivelse. Forskellige installationstyper kan udvikle sig uafhængigt og stadig være knyttet til den samme kildehistorik.
Softwarelevering
Fra fælles kildekode til en kontrolleret installation.
Microwave Pies softwareleveringsfunktioner er designet til at gøre implementering af selvhostede applikationer lettere: administrér udgivelser fra en fælles kildekode, opret den rette pakke til installationen, anvend licensering, og hold installation og opdateringer knyttet til en kendt udgivelse.
Fælles leveringsmodel
1Fælles applikationskildekodeÉn kildekodehistorik og udgivelsesidentitet.
2PlatformudgivelseByg til det tilsigtede installationsmål.
Kildepakke
Kompileret pakke
3Licenseret pakkeUdsted pakken til en bestemt implementering.
4Installér og opdatérHold installationshistorikken knyttet til den leverede udgivelse.
Funktioner
Bevar fleksible udgivelsesvalg uden at miste kontrollen.
Forskellige miljøer behøver ikke altid samme pakkeformat eller samme udgivelse på samme tidspunkt. Microwave Pie adskiller fælles applikationskildekode, genanvendelige udgivelser, pakker, licenser og installerede instanser, så hvert område kan styres bevidst.
Kildepakker
Lever applikationen som kildekode, når gennemsigtighed, direkte runtime-installation eller platformspecifik Python-installation passer bedre. Kildepakker bevarer samme udgivelses- og licensmodel som kompilerede pakker.
Kompilerede pakker
Lever en kompileret applikationspakke, når en mere selvstændig runtime foretrækkes. Kompilering er et leveringsvalg, ikke en separat produktlinje, så udgivelsens oprindelse forbliver konsistent.
Pakke- og licensstyring
Udsted en pakke, hvor licens og målmiljø allerede er tilknyttet. Pakkens livscyklus, licensstatus, downloads, installationer, opdateringer, tilbagekaldelse og lukning kan styres samlet i stedet for at skulle rekonstrueres senere.
Målspecifikke udgivelsesvalg
Raspberry Pi-, GCP-, kildekode- og kompilerede installationstyper kan af gode grunde forblive på forskellige udgivelsesniveauer. Manglende Git-commits kan gennemgås efter installationstype såvel som på tværs af applikationen.
Opdateringer styret fra brugerfladen
Administrerede applikationer kan automatisk vise, når en godkendt opdatering er tilgængelig, uden at gennemtvinge den. En administrator vælger i applikationens brugerflade, hvornår opdateringen skal klargøres og anvendes; efter genstart kan den installerede udgivelse bekræftes tilbage til den fælles leveringstjeneste, mens forholdet mellem Pakke og Licens bevares.
Implementering
Pak installationen, ikke usikkerheden.
En softwarepakke kan indeholde den implementeringskontekst, der er nødvendig for at gøre en applikationsudgivelse til en fungerende installation: målplatform, pakkeformat, installationsadfærd, udgivelsesidentitet og licensforhold.
Det gør det muligt at begynde implementeringen fra en kendt udgivelse i stedet for at bede hvert miljø om selv at genskabe beslutninger om build og levering. Når en nyere udgivelse er relevant, kan det eksisterende forhold mellem Pakke og Licens bevares, mens den valgte udgivelse opgraderes bevidst.
Applikationsudgivelser bevarer den artefakt- og Git-identitet, der faktisk blev bygget.
Tilgængelighed kan annonceres automatisk, men download, klargøring, anvendelse og genstart forbliver bevidste administratorhandlinger.
Pakker, licenser og installerede instanser forbliver forbundne gennem installation, opdatering, tilbagekaldelse og lukning.
Blackcap
Én applikation bruger modellen i dag.
Blackcap kan installeres i understøttede Raspberry Pi- og GCP-miljøer ved hjælp af kilde- eller kompilerede pakker, mens adfærden for udgivelse, pakke, licens og opdatering holdes ensartet.