Novosti iz tovarne | MicroSaaS Toolkit

Celica, naša enota infrastrukture: z enim ukazom zgrajena v 1,7 minute

2026-10-23T00:00:00Z

Tovarna, ki dodaja vedno nove produkte, potrebuje enoto infrastrukture, ki ob rasti ohrani svojo obliko. Pri nas je to celica.

Kaj je celica

Po zasnovi je celica samostojna enota, danes en strežnik, z vsem, kar produkt potrebuje, da streže uporabnikom: z vstopno točko, ki hrani certifikate TLS in imena produktov v celici, z nočnimi varnostnimi kopijami in z nadzorom, vse za lastnim požarnim zidom. Vsako okolje produkta je nameščeno v natanko eni celici, njegovo ime pa kaže nanjo.

Med delovanjem celice ne delijo ničesar: ne omrežja, ne vstopne točke, ne baze. Zunaj njih ostanejo deli, ki ne strežejo zahtevam, na primer CI in registri slik.

Celica je 22. oktobra nadomestila naš prejšnji načrt z eno osrednjo vstopno točko za vsa imena vseh produktov. Če bi produkti tekli na več strežnikih, bi vsi odpovedali skupaj s strežnikom, na katerem je ta vstopna točka, za dostop do ostalih pa bi potrebovali zasebno omrežje in odkrivanje storitev, ki bi ju vzdrževali ročno. S celicami okvara ostane v svoji celici, tovarna pa raste z novimi celicami, ne z večjim strežnikom.

Po zasnovi se produkt premakne v treh korakih: ista slika na novi celici, njegovi podatki in njegovo ime, preusmerjeno na novo celico. Produkt s seboj prinese slike, zgrajene v CI, konfiguracijo iz okolja in preverjanje zdravja, na katero počaka namestitev. Enako zahteva tudi orkestrator, kot je Kubernetes, zato ta možnost ostaja odprta.

Prva celica, zgrajena s skriptom

Enota infrastrukture je vredna toliko, kolikor stane naslednja. bin/cell.sh build iz svežega strežnika z Ubuntujem naredi celico, za vsak del pa uporabi skript iz repozitorija, ki mu pripada: nastavitve strežnika, požarni zid, vstopno točko, nadzor in varnostne kopije.

Ukaz smo 23. oktobra pognali na začasnem strežniku v drugem podatkovnem centru: strežnik je bil pripravljen v pol minute, celica v 1,7 minute. Nato smo nanj namestili nespremenjeno produkcijsko izdajo produkta v uporabi in njegovi bazi obnovili iz izvozov prejšnje noči. Celoten tek je trajal 3,8 minute in vseh 13 preverjanj je uspelo, od primerjave števila vrstic z izvozi do spletne strani in API-ja produkta, ki sta odgovorila prek nove vstopne točke. Imena produkta namenoma nismo preusmerili na kopijo, zato ni prejela nobene zahteve strank; strežnik smo nato izbrisali.

Naslednja celica se začne z istim ukazom, čas prve pa je zapisan.

Stran, ki je predstavila naš gradnik za oblikovni sistem, zdaj temelji na njem

2026-10-21T00:00:00Z

Reputo in Leadgener imata od 13. oktobra pripet en sam gradnik za oblikovni sistem, ta stran pa je o tem poročala še isti dan. Gradnika sama ni uporabljala: imela je lastne vrednosti barv za obe temi, pisavo IBM Plex Sans namesto pisave Inter, ki jo določa gradnik, lastne gumbe in lasten okvir fokusa.

En paket, dve zapisani izjemi

Stran smo 21. oktobra 2026 prenesli na gradnikov paket npm, pripet na različico 1.1.0. V svetli temi zdaj površine, besedilo in obrobe strani sledijo vlogam gradnika. Gumbi, debelina pisave v naslovih, pisava besedila in okvir fokusa na kontrolnikih so gradnikovi. Modra barva toolkita je v brand.css: dvanajst barvnih vlog iz pogodbe znamke gradnika, ki jih v testih strani preveri gradnikov assertBrand, tako kot v Reputu in Leadgenerju. Svetlo modra barva za dejanja na tem testu pade: njen kontrast je 1,80 : 1, zahtevano pa je vsaj 4,5 : 1.

Deli, za katere gradnik nima ustreznika, na primer tloris tovarne, ostanejo del strani; za dva od njih odločitev o prevzemu gradnika zapiše, zakaj ostajata zunaj njega. Gradnik nima temne teme in noben produkt je ne potrebuje, zato po našem pravilu žetve ne spada v gradnik; 13 testov zagotavlja, da barve besedila in gumbov v temni temi strani ohranijo kontrast vsaj 4,5 : 1. Prav tako gradnik nima čipa za filtriranje, zato stikala, s katerimi filtrirate tloris tovarne in novice, ostajajo kontrolniki strani, zgrajeni iz oblikovnih žetonov gradnika, dokler čipa ne bo potreboval kateri od produktov.

Tailwind v plasteh gradnika

Gradnik določa sedem kaskadnih plasti (cascade layers); zadnja, product, je namenjena lastnemu CSS strani. Tailwind, s katerim gradimo stran, CSS izpiše zunaj vseh plasti, tak CSS pa premaga vsako plast ne glede na specifičnost: Tailwindova ponastavitev slogov bi povozila sloge gumbov gradnika. Zato gradnja Tailwind požene dvakrat: njegovo ponastavitev postavi v plast gradnika za ponastavitev, vse drugo pa v plast product. Nato lahko gradnjo ustavijo tri preverbe: plasti morajo slediti v vrstnem redu gradnika, zunaj plasti ne sme biti nobenega pravila razen @font-face, vsak lokalni url() pa mora kazati na datoteko, ki jo je zapisala gradnja. Vsakega od teh pogojev smo namenoma prekršili in vsakič je preverba gradnjo ustavila s svojim sporočilom.

Ista gradnja teče med izdelavo slike Docker na veji main, namestitev pa čaka na to sliko: prvi cevovod je pridobil gradnik, zgradil sliko in namestitev končal 83 sekund po združitvi spremembe.

CSS gradnika tu torej deluje brez njegovih komponent React: dva zagona postavita Tailwindov CSS v plasti gradnika, gradnja pa se ustavi, če kako pravilo ostane zunaj njih ali se njihov vrstni red spremeni.

Predpomnilnik slojev za gradnjo slik in kanarček, ki je ujel njegovo prvo izdajo

2026-10-20T00:00:00Z

Skupni izvajalniki (runnerji) v GitLabu vsako opravilo začnejo s praznim Dockerjem. Gradnja slike z gradnikom za CI/CD je zato ob vsakem zagonu znova obnovila pakete NuGet in od začetka prevedla API, tudi kadar se ni spremenila nobena datoteka zaledja.

Predpomnilnik je v registru

Gradnik za CI/CD 1.4.0, ki smo ga izdali 20. oktobra 2026, komponenti image-build doda vhodni parameter cache z dvema vrednostma: privzeto none in registry. Z vrednostjo registry gradnja teče z orodjem buildx na gonilniku docker-container in sloje bere iz <image>:buildcache v registru vsebniških slik projekta. Nazaj jih zapiše samo privzeta veja. Gradnja v zahtevi za združitev predpomnilnik prebere, v register pa ne potisne ničesar, zato ne more zamenjati slojev, na katere se zanaša main. Produkt, ki parametra ne nastavi, ne opazi nobene spremembe.

Predpomnilnik od datoteke Dockerfile zahteva eno stvar: obnovljeni paketi morajo ostati v sloju slike. Imenik, priklopljen z RUN --mount=type=cache, se v register nikoli ne izvozi, zato bi naslednji korak ostal brez paketov, kadar bi sloj z obnovo prišel iz predpomnilnika. Probe, produkt, ki ga vzdržujemo zato, da vsako izdajo gradnika prevzame prvi, je iz tega razloga opustil priklope predpomnilnika za NuGet.

Ujeta na pravem izvajalniku

Različica 1.4.0 je prestala teste na delovni postaji, Probova prva gradnja pa se je pet minut po izdaji končala z napako. Opravila gradnika se z Dockerjem povezujejo prek TLS, docker buildx create pa nastavitev TLS iz okolja ne sprejme. Noben drug produkt je še ni pripel. Različica 1.4.1, izdana 14 minut po različici 1.4.0, graditelja ustvari v kontekstu Dockerja, narejenem iz istih nastavitev.

Do takrat je cevovod gradnika komponento image-build le vključil in preveril, da jo GitLab sprejme, njenega skripta pa ni nikoli zagnal. Novo opravilo delivery:image-build-test ta skript zažene na Dockerju s TLS, kakršnega imajo opravila produktov, in z registrom, zagnanim v istem Dockerju. Preveri, ali privzeta veja predpomnilnik zapiše, ali ga nov graditelj prebere, ali ga druga veja prebere in v register ne potisne ničesar ter ali gradnja brez predpomnilnika še deluje. S predlogo različice 1.4.0 se 7 od 10 preverjanj konča z napako.

Prva gradnja slike API na Probovi veji main je trajala 91 sekund in zapisala predpomnilnik. Ponovni zagon iste potrditve, najugodnejši primer, je trajal 33 sekund, koraka dotnet restore in dotnet publish pa sta prišla iz predpomnilnika v registru. V Probovi datoteki Dockerfile je sloj z obnovo odvisen samo od datotek projektov in nastavitev gradnje, zato bi ga potrditev, ki spremeni samo kodo, morala uporabiti znova.

Kdor želi predpomnilnik uporabiti, pripne različico 1.4.1, nastavi cache: registry na slikah s počasno obnovo, oznako slike buildcache izvzame iz pravila za čiščenje registra in iz datoteke Dockerfile najprej odstrani priklope predpomnilnika za pakete.

Varnostna preverjanja, ki jih produkt prevzame z gradnikom za CI/CD

2026-10-19T00:00:00Z

Pregled skrivnosti, preverjanje paketov NuGet in preverjanje naslovov, ki morajo po namestitvi ostati zaprti, smo 19. oktobra 2026 prenesli iz cevovodov naših produktov v gradnik za CI/CD. Produkt, ki začne z Reputovim cevovodom, ima vsa tri preverjanja že od prvega cevovoda. Vstopno preverjanje uporabniškega vmesnika je npm audit poganjalo že prej.

Tri preverjanja v gradniku

Gradnik za CI/CD 1.1.0 doda komponento secret-scan, ki z orodjem gitleaks pregleda nove potrditve v cevovodu: pri zahtevi za združitev njene potrditve, na veji pa vse od njenega prejšnjega stanja. Ne čaka na nobeno drugo opravilo, zato gradnje nikoli ne zadržuje. Komponenta dotnet-test takoj po obnovi paketov zažene dotnet list package --vulnerable --include-transitive in pade ob ranljivosti visoke ali kritične stopnje. Pregled uporabi isto obnovo, zato traja le nekaj sekund in ne zahteva druge. Izklopi se z vhodnim parametrom vulnerability_scan: false, ki ga dokumentacija gradnika dovoli samo z razlogom in datumom v cevovodu produkta.

Različica 1.2.0, izdana isti dan, komponenti deploy doda vhodni parameter closed_urls, seznam naslovov, ki morajo po namestitvi vrniti 401, 403 ali 404. Odgovor 2xx ali 3xx preverjanje takoj označi kot neuspešno, brez ponovnih poskusov.

Prevzeto na dan izdaje

Reputo in Leadgener sta popoldne prešla na različico 1.1.0. Oba cevovoda sta zagnala pregled skrivnosti in pregled paketov NuGet; noben pregled ni ničesar našel.

Zvečer sta oba produkta na gradniku za CI/CD 1.3.0 v closed_urls navedla tri naslove: skrbniško konzolo strežnika za identiteto, njegov realm master in stran Swagger. Vsaka namestitev zdaj dokaže, da ostanejo zaprti: Reputova namestitev v razvojno okolje ob 17.43 UTC in Leadgenerjeva ob 17.47 UTC sta vse tri zabeležili kot zaprte (404).

Preverjanje je v gradniku, pravila pa ne, in to namerno: kaj naslov zapre, se od produkta do produkta razlikuje (pravilo v prehodu, nastavitve API-ja), ali je zaprt, pa je povsod isto vprašanje. Nov produkt, ki prevzame Reputov cevovod, z njim podeduje tudi vse tri naslove, zato se njegova prva namestitev konča z napako, če kaj od tega, kar jih zapira, manjka.

Toolkit 1.0.3 je manj kot uro po izdaji tekel v vseh treh produktih v uporabi

2026-10-19T00:00:00Z

Vsak produkt toolkit pripne v eni vrstici, izdaja pa nima nobenega učinka, dokler produkt v tej vrstici ne spremeni različice. Do 19. oktobra 2026 smo to delali ročno: ob izdaji smo pripeto različico popravili v vsakem produktu posebej in šele iz njegovega cevovoda izvedeli, ali se še zgradi.

Dva skripta, pred izdajo in po njej

Skript factory/check_consumers.py vsak aktiven produkt iz registra tovarne, ki pripenja toolkit, zgradi s kopijo toolkita namesto z objavljenimi paketi, še preden karkoli izdamo. Skript factory/propose_upgrade.py nato odpre zahtevo za nadgradnjo v vsakem produktu, ki pripenja starejšo različico. Spremeni samo pripeto različico, v opisu vsake zahteve pa so opombe k vsem izdajam, novejšim od pripete različice, zato tisti, ki zahtevo združi, vidi, kaj mora produkt ob nadgradnji narediti.

Toolkit 1.0.3 je odpravil edino mesto, kjer se je paket iz nižje plasti skliceval na paket iz višje: Tenancy.Runtime ni več odvisen od Organizations.Api. Knjižnico Stripe poleg tega pripne na točno določeno različico. Pred izdajo je check_consumers.py s to spremembo zgradil vseh pet produktov.

Potek dneva

Vseh 19 paketov različice 1.0.3 je bilo objavljenih ob 16.00 UTC. Prvi pravi zagon skripta propose_upgrade.py je v repozitorije Gostlyja, MojRazpisa in SnapMinda potisnil veje, zahtev za združitev pa ni odprl, ker je izvorni projekt vzel iz mape, v kateri je tekel. Popravek zahteve ustvari prek API-ja z imenom projekta in ponovnemu zagonu dovoli, da dokonča, kar je prejšnji začel: ponovni zagon je vse tri odprl ob 16.04. Reputo in Leadgener sta izdajo prevzela vsak v svoji zahtevi, skupaj z novimi varnostnimi pregledi gradnika za CI/CD. Do 16.09 je bilo združenih vseh pet zahtev.

Namestitev v produkcijo še vedno sproži lastnik s pritiskom na gumb. MojRazpis in SnapMind sta z različico 1.0.3 v produkciji tekla od 16.39, Gostly, pri katerem gre sprememba najprej na razvojno vejo, pa od 16.54. Od objave do zadnje namestitve v produkcijo je minilo 54 minut, v registru tovarne pa je izdaja zapisana z datumom, ko je dosegla vse produkte v uporabi.

Nič ni zahtevalo, da se pet produktov nadgradi hkrati: vsaka zahteva je imela svoj cevovod, produkt, ki zahteve ne združi, pa ostane na stari različici. Različica 1.0.3 ni bila varnostna izdaja. Po isti poti bo potoval varnostni popravek: najprej ga bomo zgradili v vseh produktih, nato ga bomo predlagali vsakemu posebej.

Gradnik za CI/CD: en cevovod in ena namestitev namesto dveh ročno vzdrževanih kopij

2026-10-15T00:00:00Z

Reputo in Leadgener, naša produkta v razvoju, smo gradili, testirali in nameščali z dvema kopijama istega cevovoda in istih skriptov za namestitev, ki smo ju prenašali ročno. Do 15. oktobra sta se kopiji razšli. Skripta za namestitev (116 in 111 vrstic) sta se razlikovala v 47 vrsticah, skripta, ki na strežniku zaženeta vsebnike (64 in 82 vrstic), pa v 66. Del razlik so imena produktov in komentarji, del pa delovanje: produkta sta varnostno kopijo delala vsak na svoj način. Popravek v eni kopiji ni prišel do druge, Leadgenerjev prvi cevovod pa je pri kopiranju že izgubil zastavico za gradnjo.

Šest komponent in slika vsebnika ops

Gradnik za CI/CD 1.0.0 smo izdali 15. oktobra 2026. Za gradnjo in namestitev naredi to, kar so paketi NuGet naredili za zaledje in gradnik Keycloak za identiteto: vsebuje šest komponent CI/CD za GitLab (testi zaledja, vstopno preverjanje uporabniškega vmesnika, vzporedni testi uporabniškega vmesnika, gradnja slik, namestitev in obnovitveni test) ter sliko vsebnika ops, v kateri tečeta namestitev in obnovitveni test. Produkt vsako komponento vključi v pripeti različici @delivery-v1.0.0. Različice latest ni, dnevnik sprememb pa vsako spremembo označi glede na to, česa se dotakne: [contract], [behaviour] ali [pipeline].

Različica 1.0 je zvest prenos obeh cevovodov; zasnova navaja vsako spremembo delovanja z razlogom. Varnostna kopija sledi Leadgenerjevi zasnovi: izvoz baze s kontrolnimi vsotami in številom vrstic vsake tabele v bazi aplikacije. Gradnik spremeni eno stvar: vrstice prešteje znotraj istega posnetka stanja, iz katerega nastane izvoz. Produktu ostanejo njegovi vhodni parametri, datoteke Compose in kavlji za korake, ki jih potrebuje samo on, na primer za pripravo realma v Keycloaku.

Dokazano na obeh produktih še isti dan

Pred izdajo je Reputo prevzel gradnik, pripet na določeno potrditev toolkita. Primerjalno poročilo je cevovod pred prevzemom in po njem primerjalo opravilo za opravilom, zahteva za združitev pa pojasni vsako razliko. Število uspešnih testov se ni spremenilo: 2.298 testov zaledja in 2.591 testov uporabniškega vmesnika. Na veji main je namestitev iz gradnika naredila varnostno kopijo obeh baz, prek Reputovega kavlja pripravila Keycloak in prestala preverjanje zdravja, obnovitveni test pa je to kopijo obnovil v začasen vsebnik: 33 tabel, vsaka z enakim številom vrstic kot v varnostni kopiji.

Reputo je nato pripel različico 1.0.0, Leadgener pa je prešel še isti večer. Njegov prvi obnovitveni test na gradniku je preveril 25 tabel, prek lastnega kavlja pa še, da je vseh 3.391 datotek, na katere kaže baza, na mestu in da se njihove kontrolne vsote ujemajo. Iz obeh produktov smo skripte za namestitev odstranili, Reputov .gitlab-ci.yml pa se je skrčil z 290 na 172 vrstic.

Spremembo skupnih opravil, namestitve, varnostne kopije ali obnovitvenega testa zdaj naredimo enkrat, v gradniku; kar potrebuje samo en produkt, ostane v njegovih vhodnih parametrih in kavljih.

Gradnik za oblikovni sistem 1.1.0: nov videz, izdan enkrat, pripet dvakrat

2026-10-14T00:00:00Z

Gradnik za oblikovni sistem 1.0 je ohranil videz, ki so ga naši produkti že imeli: pisavo Arial, oglate vogale, obrobe gumbov in vnosnih polj debeline 2 px, besedilo z velikimi tiskanimi črkami na značkah in ploščicah KPI ter temno nogo strani. Želeli smo, da bi bili videti kot sodobni produkti SaaS. Z dvema kopijama oblikovnega sistema bi to pomenilo dvakrat isto preoblikovanje; s skupnim gradnikom, ki ga imamo od 13. oktobra, je to ena sama izdaja.

Nov videz, iste komponente

Gradnik za oblikovni sistem 1.1.0 smo izdali 14. oktobra 2026. Arial je zamenjala pisava Inter, ki je del paketa in se nikoli ne nalaga iz omrežja CDN za pisave. Vogali so rahlo zaobljeni: 3 px pri značkah, 4 pri kontrolnikih in 6 pri karticah. Obrobe gumbov in vnosnih polj so tanjše, 1 px, kartice imajo mehko senco, noga strani pa je svetla plošča.

HTML in zgradba strani sta ostala enaka; nobene lastnosti komponent nismo odstranili ali preimenovali. Videz je del jedra: produkt še vedno nastavi le svojih dvanajst barvnih vlog, saj bi z vlogami za pisavo, zaobljenost ali senco produkti znova začeli odstopati drug od drugega. Kar gradnik zagotavlja, se ni spremenilo: okvir fokusa, površine za dotik velikosti 44 px, kontrast in toni stanj, ki jih poleg barve loči tudi oblika simbola.

Med različicama 1.0.1 in 1.1.0 se je v gradniku spremenilo 33 slogovnih datotek (dodanih 466 vrstic, odstranjenih 146) in vseh 384 referenčnih posnetkov.

Kaj so spremenili produkti

Reputo in Leadgener pripneta gradnik vsak v eni vrstici datoteke package.json svojega uporabniškega vmesnika, iz katerega se zgradijo tudi strani za prijavo. Reputo je pripeto različico z 1.0.0 dvignil na 1.1.0 uro po tem, ko smo sprejeli zahtevo za združitev gradnika, zato je dobil tudi popravke iz 1.0.1. V kodi aplikacije, v mapi src uporabniškega vmesnika, so se spremenile tri datoteke (dodanih 20 vrstic, odstranjenih 7): Reputove kartice preverjanj, incidentov in zapisov DNS zdaj berejo nove žetone gradnika za zaobljenost in senco kartic.

Leadgener je 1.1.0 pripel dve uri pozneje. V kodi aplikacije njegove slogovne datoteke zdaj namesto fiksno vpisane vrednosti 700 berejo žetone gradnika za debelino pisave. En zaslon je potreboval spremembo kode: tabela priložnosti ima devet stolpcev, zato uporablja novo možnost stackBelow="wide". Ko je sama ožja od 1160 px, vsako vrstico prikaže kot seznam poimenovanih polj, datum in uro pa izpiše kot dva ločena dela.

Na toolkitu nov videz pomeni manjšo različico: pripnete jo, opravite preverjanja, ki jih dnevnik sprememb navaja za to izdajo, in znova pregledate zaslone; tabela, preširoka za svoj okvir, dobi eno lastnost.

Register tovarne: kaj ima pripeto vsak produkt in ali se to ujema z repozitorijem

2026-10-13T00:00:00Z

Produkt ima naše gradnike pripete v svojem repozitoriju: različico toolkita v Directory.Build.props, gradnik Keycloak v Dockerfilu, gradnik za oblikovni sistem pa v frontend/package.json. Do 11. oktobra ni bilo nikjer zapisano, kateri produkt uporablja katero različico in ali je skupna sprememba že prišla v produkcijo.

En zapis, ki ga preverjamo

Register produktov factory/products.toml smo dodali 11. oktobra 2026. Za vsak produkt navaja fazo, lastnika, integracijsko in produkcijsko vejo, različice v kits.nuget, kits.keycloak in kits.design_system, za produkt v produkciji pa še opravilo za namestitev in potrditev (commit), ki je nameščena v produkciji.

Skript factory/check_registry.py ta zapis primerja z repozitorijem vsakega produkta na origin/<branch>, nikoli z delovno kopijo, zato delo, ki še ni potisnjeno, ne šteje. Z --fetch najprej osveži vse lokalne kopije, z --gitlab pa GitLab vpraša, katero potrditev je namestilo zadnje uspešno opravilo za namestitev. Vsaka ugotovitev je ena vrstica z oceno. DRIFT pomeni, da se register in repozitorij ne ujemata, napačen pa je lahko kateri koli od njiju. FAIL označuje tveganje za obratovanje, na primer kopijo toolkita v repozitoriju namesto paketov, ciljno ogrodje, ki mu bo podpora potekla v manj kot 90 dneh, ali pripeto različico oblikovnega sistema, ki ni enaka tisti v registru. Če najde vsaj en FAIL ali DRIFT, skript konča z izhodno kodo 1.

Kaj je preverjanje našlo 13. oktobra

Glava registra zahteva, da register posodobimo v isti zahtevi za združitev kot spremembo, zaradi katere zapis drži. Za pripeto različico gradnika to pravilo ne more veljati: spremeni se v repozitoriju produkta, register pa v našem. V register smo 12. oktobra za Reputo in Leadgener vpisali gradnik Keycloak 1.0.1. Še isti večer sta oba prešla na 2.0.0. Naslednji dan sta register spremenili dve zahtevi za združitev, a teh vrstic ni popravila nobena.

Preverjanje 13. oktobra je med drugimi ugotovitvami izpisalo tudi ti dve vrstici:

DRIFT  reputo       main: Keycloak kit pins ['2.0.0'], registry says 1.0.1
DRIFT  leadgener    main: Keycloak kit pins ['2.0.0'], registry says 1.0.1

Pripeti različici oblikovnega sistema, vpisani v register nekaj ur prej, sta se v obeh produktih ujemali z registrom. Popravek je ena vrstica na produkt v products.toml.

Za ekipo, ki gradi na toolkitu, register preverja pravilo, ki smo ga postavili za svoje nadgradnje: nadgradnja je končana, ko teče v produkciji, ne že ob združitvi zahteve zanjo. Z --gitlab preverjanje pri produktu v produkciji prebere različico toolkita iz potrditve, ki jo je GitLab nazadnje namestil, in opozori, če ta ni enaka različici v registru. Register za vsak produkt hrani različice gradnikov, ki jih pripenja njegova integracijska veja, en zagon preverjanja pa pokaže, kje se zapis in repozitorij razhajata.

Gradnik Keycloak: ena pripeta slika, tema za vsak produkt

2026-10-13T00:00:00Z

Vsak produkt prijavlja uporabnike prek svojega Keycloaka, paketi API iz toolkita pa zaupajo temu, kar ta Keycloak zapiše v žeton. Reputo in Leadgener sta sliko prej gradila iz quay.io/keycloak/keycloak:26.0, torej iz oznake, ki se premakne z vsako popravno različico. Zato sta lahko dve gradnji iz iste potrditve (commit) vsebovali različni različici Keycloaka.

Kaj gradnik vsebuje in česa ne

Odločili smo se 11. oktobra 2026: gradnik Keycloak je ena osnovna slika, ki vsebuje le tisto, kar mora biti enako v Keycloaku vsakega produkta. To so Keycloak, pripet na povzetek; orodje jq, pripeto na kontrolno vsoto; 32 Keycloakovih sporočil za prijavo v slovenščini; in dva ukaza, ki se v vsebniku izvedeta prek docker exec.

setup pripravi, kar API prebere iz žetona: občinstvo (audience), vloge realma, zbrane v zahtevku roles, ki ga bere ASP.NET, in deklarirani atribut organization_id, ki bi ga Keycloak 26 sicer brez opozorila zavrgel.
require-terms sprejem pogojev uporabe nastavi kot zahtevano dejanje za vsakega uporabnika, zato Keycloak žetona pred sprejemom ne izda. Shrani se le čas sprejema.

Privzetih vrednosti produktov gradnik ne vsebuje: ime realma, identifikatorji odjemalcev in izvori (origins) so v ovojnem skriptu produkta, setup pa se ustavi, preden kar koli spremeni, in navede vsako manjkajočo spremenljivko. Tudi teme za prijavo ne vsebuje, ker tema na skupni oblikovni sistem doda znamko svojega produkta. Dockerfile produkta v prejšnji fazi zgradi JAR s temo, nato pa:

FROM <kit image>:<X.Y.Z>@sha256:<digest>
COPY --from=theme /app/keycloak-theme/dist_keycloak/reputo-keycloak-theme.jar /opt/keycloak/providers/
RUN /opt/keycloak/bin/kc.sh build --db=postgres --health-enabled=true

Testiran, pripet, nadgrajen po izbiri

Vsaka zahteva za združitev, ki spremeni gradnik, nad zgrajeno sliko požene šest zbirk testov. Ena od njih vsako slovensko sporočilo primerja s Keycloakom v sliki: ključ mora v Keycloaku obstajati, ograde pa morajo ostati enake.

Oznake latest ni, objavljena različica pa se nikoli ne prepiše. Reputo in Leadgener sta imela 13. oktobra pripeto isto različico z istim povzetkom. Dnevnik sprememb označi, kaj različica zahteva od produkta: [keycloak] (najprej varnostna kopija podatkovne baze), [contract] (spremenil se je ukaz, spremenljivka ali pot) ali [behaviour] (pripravljeni realm je drugačen). Vsaka sprememba različice Keycloaka pomeni novo glavno (major) različico gradnika, ker Keycloak svojo podatkovno bazo migrira samo v eno smer. Do 13. oktobra je izšlo pet različic gradnika; kako je nastal, opisuje objava o pravilu žetve.

Za ekipo, ki gradi na toolkitu, to pomeni, da pravila identitete pridejo s sliko: žeton vsebuje, kar API preverja, in Keycloak ga ne izda, dokler uporabnik ne sprejme pogojev. Strani za prijavo in vrednosti realma ostanejo vaše.

En oblikovni sistem, plast znamke za vsak produkt

2026-10-13T00:00:00Z

Naš oblikovni sistem je nastal v Reputu: oblikovni žetoni v CSS, komponente React, pravila linterja, ki zaslonom ne dovolijo lastnega oblikovanja, in katalog. Leadgener je 8. oktobra prekopiral njegovih 209 datotek in zamenjal barvno paleto. Štiri dni pozneje se je 26 datotek, skupnih obema kopijama, razlikovalo po vsebini, 14 pa jih je imela le ena. Nekatere razlike so bile Leadgenerjeve lastne komponente, ena pa popravek, ki je ostal tam, kjer je nastal: ožji notranji odmik zavihkov, s katerim trije zavihki na 375 px širokem zaslonu telefona ostanejo v eni vrstici. V Reputu so se zavihki še vedno prelamljali.

Jedro je skupno, znamka ni

Po našem pravilu žetve smo videz in uporabniško izkušnjo namenoma kopirali. Oblikovni sistem smo 12. oktobra iz tega pravila izvzeli. Jedro sistema določa kakovost vmesnika, zato se med produkti ne sme razlikovati: okvir fokusa, površine za dotik velikosti 44 px, kontrast, toni stanj, ki jih poleg barve loči tudi oblika simbola, ter lestvici velikosti pisave in razmikov. Iz njega je nastal gradnik za oblikovni sistem: paket npm, ki ga izdajamo kot druge gradnike, z datiranim razdelkom v dnevniku sprememb in zaščiteno oznako.

Produktu ostane plast znamke: brand.css z natanko dvanajstimi barvnimi vlogami, znak in lastne komponente s predpono produkta. Testi produkta kličejo assertBrand, ki javi napako, če kakšna vloga manjka, če datoteka nastavi katero koli drugo lastnost gradnika, če vloga ne doseže najmanjšega kontrasta po WCAG 2.1 ali če bi barvo za dejanja lahko zamenjali z barvo uspeha, opozorila ali napake. Ogrodje aplikacije, tema za prijavo in predstavitvena stran ostanejo kopije, vendar v Reputu in Leadgenerju najprej uvozijo slogovno datoteko gradnika, nato brand.css.

Najprej primerjano, nato izdano

Gradnik 1.0.0 je zvest prenos Leadgenerjeve kopije. Vsak vnos kataloga smo zajeli pri širinah 375, 768 in 1366 px ter gradnik z obema produktoma primerjali piksel za pikslom. Razen vnosov, ki so navedeni kot drugačni že po zasnovi, je edina sprememba izrisa popravek zavihkov, ki zdaj doseže tudi Reputo. Njegovih 384 posnetkov je postalo referenca za vsako zahtevo za združitev, ki gradnik spremeni.

Pred objavo opravilo za izdajo zahteva, da se v registru preveri preizkusno objavljen kandidat iz iste kode, nato pa teste ponovno požene nad potrditvijo združitve (merge commit): za 1.0.0 jih je bilo 615. Reputo in Leadgener sta prevzela kandidata, svoj katalog in vseh devet strani teme za prijavo primerjala s tem, kar sta izrisala prej, in isti dan pripela 1.0.0.

Če gradite na toolkitu, so barve vašega produkta ena datoteka, ki jo gradnik preveri: paleta s prešibkim kontrastom pade na testu znamke, še preden pride na zaslon. Popravek, kot je odmik v zavihkih, nastane enkrat, v gradniku, ne v vsaki kopiji.

Keycloak 26.0 → 26.8: kaj nas je presenetilo in kam smo to zapisali v gradniku

2026-10-12T00:00:00Z

Gradnik Keycloak 1.x je bil pripet na 26.0.8, ki za 26.8 zaostaja za osem manjših različic, in ni dobil nobenega popravka iz teh različic. Če bi vsak produkt nadgrajeval sam, bi vsak v svojem cevovodu naletel na ista presenečenja.

Ena nadgradnja, v gradniku

Gradnik Keycloak 2.0.0 s Keycloakom 26.8.0 smo izdali 12. oktobra 2026. V Dockerfilu gradnika sta to dve vrstici: FROM s povzetkom (digest) in vrstica LABEL, ki ponovi različico. Zbirka testov strukture zdaj preveri, ali se LABEL ujema z vrstico FROM. Kar nas je presenetilo, smo zapisali v test ali dnevnik sprememb.

Test, ki ni prebral ničesar. Keycloak 26.8 poleg JAR-a s temami prinaša še keycloak-themes-vendor-*.jar. Test sporočil je iskal keycloak-themes-*.jar; vzorec je zajel obe datoteki, zato test ni kopiral nobene in je bilo videti, da Keycloak ne pozna nobenega od 32 slovenskih ključev. Prevod je bil v redu, test ne. Zdaj sprejme natanko en JAR in sam javi napako, če prebere manj kot 100 angleških ključev.
Nove privzete vrednosti realma. Realm, ki ga pripravi gradnik, se od tistega iz različic 1.x razlikuje le po Keycloakovih privzetih vrednostih za nov realm, kot kaže primerjava referenčnih izvozov realma. Med njimi so tri nova zahtevana dejanja, zahteva po shranjenem ključu (resident key) in preverjanju uporabnika pri prijavi WebAuthn brez gesla, odsotnost glave X-XSS-Protection in odjemalec realm-management, ki je v skrbniškem API-ju le za branje. Priprava realma se ni spremenila in sprejem pogojev uporabe ostaja privzeto zahtevano dejanje. Keycloak obstoječi realm migrira in ga ne ustvari znova, zato se njegove vrednosti lahko razlikujejo.
Teme za prijavo. Od 26.7 se predloge izvajajo s privzetimi nastavitvami FreeMarkerja 2.3.32, od 26.5 pa Keycloak HTML prikaže le še v sporočilu termsText; prav to sporočilo lahko gradnik 2.1.0 nastavi tako, da vsebuje povezavi do pogojev uporabe in politike zasebnosti. Pred izdajo smo na novi sliki zgradili Reputovo temo: strani za prijavo in pogoje sta se prikazali brez napak v predlogah.

Dnevnik sprememb navaja še: PostgreSQL 14 ali novejši, enkratne povezave za zahtevana dejanja, zavrnjene preusmeritvene naslove URI s parametrom state ali code ter korake za nadgradnjo iz gradnika 1.x.

Reputo in Leadgener sta prešla isti dan, vsak s svojo zahtevo za združitev, ki spremeni le pripeto različico gradnika in komentar ob njej. Še isti večer smo 26.8.0 namestili v obe razvojni okolji.

Ekipa, ki uporablja gradnik Keycloak, dobi nadgradnjo Keycloaka kot različico gradnika, ki je te teste že prestala, spremembe pa so zapisane v dnevniku sprememb. Na vas je, da pred prvim zagonom nove različice naredite varnostno kopijo baze Keycloaka, spremenite pripeto različico, na novi sliki zgradite svojo temo za prijavo, če jo imate, in v razvojnem okolju enkrat pregledate strani za prijavo, registracijo in pogoje.

Izdali smo okvarjen gradnik Keycloak 1.0.0

2026-10-12T00:00:00Z

Cevovod CI gradnika Keycloak je 11. oktobra 2026 na potrditvi različice 1.0.0 pognal vse svoje zbirke testov in javil FAILS=0. Nato je opravilo za izdajo sliko naložilo v register. Štirinajst minut pozneje se je namestitev Reputa v razvojno okolje ustavila pri pripravi realma:

bash: /opt/microsaas/keycloak/setup: Permission denied

Napaka in zakaj je testi niso ujeli

Imenik /opt/microsaas/keycloak je imel dovoljenja 644. Brez bita za izvajanje vanj Keycloakov uporabnik (uid 1000) ni mogel vstopiti, zato se nista mogla zagnati ne setup ne require-terms. Dockerfile tega imenika ni ustvaril izrecno: nastal je kot nadrejeni imenik pri ukazu COPY --chmod=644 za datoteko s slovenskimi sporočili, njegova dovoljenja pa določi BuildKit, ki izvaja gradnjo.

Različico 1.0.0 sta zgradila dva BuildKita. Testno opravilo je pognalo docker build z BuildKitom, vgrajenim v Docker: imenik je dobil 755. Opravilo za izdajo je uporabilo buildx s privzeto sliko moby/buildkit (brez pripete različice; takrat je bila to v0.33.1): imenik je dobil 644. Ista potrditev, isti Dockerfile, dve sliki. Vse zbirke testov so uspele na sliki, ki je nismo izdali, izdane pa ni preveril noben test.

Razvojno okolje Reputa je delovalo naprej, ker je realm shranjen v podatkovni bazi. Različico 1.0.0 sta pripela le Reputo in Leadgener, ki še nista v produkciji.

Testiramo to, kar izdamo

Sprejeli smo pravilo: testiramo prav tisti artefakt, ki ga izdamo, zgrajen z orodjem, ki ga tudi objavi. Glavni popravek smo združili isti večer, različico 1.0.1 pa objavili naslednje jutro. V CI se je spremenilo tole:

En BuildKit, pripet na različico in povzetek (digest) v release/builder.sh, zgradi sliko za teste in sliko za register. Na povzetek je pripet tudi frontend, ki tolmači Dockerfile.
Dockerfile vse imenike gradnika ustvari z dovoljenji 755, preden vanje kopira datoteke, zato ta niso več odvisna od orodja za gradnjo.
Zbirka testov strukture kot uid 1000 preveri, da je mogoče vstopiti v vsak imenik ter prebrati ali zagnati vsako datoteko.
Po nalaganju opravilo za izdajo prenese sliko, ki jo vrne register, in testira prav njo. Od različice 1.0.2 vsako pot pod /opt/microsaas z dovoljenji in lastnikom v slikah za amd64 in arm64 primerja z vnaprej določenim seznamom, oznako različice pa ustvari šele, ko preverjanje obeh slik uspe.

Za ekipo, ki gradi na toolkitu, to pomeni: vsaka različica gradnika Keycloak od 1.0.2 naprej je bila testirana na sliki, ki jo je zgradil isti BuildKit kot objavljeno sliko, po objavi pa še enkrat preverjena na sliki, ki jo prenesete, za obe platformi. Povzetek slike vzamete iz opomb ob izdaji, različica, ki po nalaganju ne prestane preverjanja, pa nima ne opomb ne oznake: v dnevniku sprememb je označena kot okvarjena, popravek pa izide kot naslednja popravna različica.

Predstavitvena stran brez zahtev strežnikom tretjih oseb pred privolitvijo

2026-10-12T00:00:00Z

Do 12. oktobra je stran microsaaskit.dev, še preden je obiskovalec prebral prvo besedo, prenesla pisavo IBM Plex iz storitve Google Fonts, Font Awesome iz omrežja CDN, Tailwind kot skript, ki je sloge prevajal v brskalniku, in Google Analytics. Zadnjo različico pred spremembo smo znova zgradili in njeno domačo stran naložili v Chrome brez grafičnega vmesnika (headless): ob prvem obisku je, ne da bi obiskovalca kaj vprašala, poslala 11 zahtev petim strežnikom tretjih oseb; zahteve za Google Analytics, ki smo jo pri meritvi blokirali, nismo šteli.

Kaj smo spremenili

Google Analytics se zdaj naloži šele, ko obiskovalec izbere »Dovoli analitiko«. Gumb »Zavrni« je tik ob njem, enako velik in enako oblikovan, povezava »Nastavitve piškotkov« v nogi pa pasico odpre znova. Pisave zdaj gostimo sami: dve družini IBM Plex v podmnožicah latin in latin-ext, 14 datotek, ki jih gradnja prekopira iz paketov Fontsource. Namesto Font Awesome stran uporablja ikone Lucide in Simple Icons (logotipi znamk); gradnja jih v vsako stran vgradi kot eno zbirko SVG (sprite) in se konča z napako, če stran uporabi ikono, ki je v zbirki ni. Tailwind se prevede ob gradnji.

Istega dne sta nastali dve statični strani, angleška na / in slovenska na /sl/, povezani z atributom hreflang; / je privzeta (x-default), sitemap.xml pa pri vsaki strani navaja obe jezikovni različici. Tloris tovarne nariše JavaScript; brez njega je besedilo tlorisa le blok JSON. Pajku, ki JavaScripta ne izvaja, zato llms.txt ponudi ista dejstva v Markdownu, ustvarjena iz istih datotek en.json in factory-data.js kot stran.

Seznam zahtev

Dokaz ni izvorna koda, temveč seznam zahtev v brskalniku. Na živi strani smo naložili /, /sl/ in obe obvestili o zasebnosti, iz lokalne gradnje pa še strani z novostmi, v Chromu brez grafičnega vmesnika, z novim profilom in brez privolitve, ter prek protokola DevTools zabeležili vsako zahtevo. Vse zahteve so šle na izvor (origin), s katerega je bila stran naložena, od 7 do 16 na stran. Slovenske strani so prenesle še datoteke pisav latin-ext, za č, š in ž.

V lokalni gradnji smo nato kliknili »Dovoli analitiko«. Pojavila sta se dva strežnika: eden streže skript gtag, na drugem je končna točka za zbiranje podatkov, vsak z eno zahtevo na stran. Ko smo v »Nastavitvah piškotkov« izbrali »Zavrni«, piškotkov _ga ni bilo več, ponovno naložena stran pa je zahteve spet pošiljala samo na svoj izvor.

Za ekipo, ki gradi na toolkitu: pasica za privolitev je trditev, seznam zahtev pa njen test. Preden objavite predstavitveno stran svojega produkta, jo naložite z novim profilom brskalnika in brez privolitve ter preglejte seznam strežnikov. Če vsebino strani nariše JavaScript, iz istega vira ustvarite še besedilno različico, kot je tu llms.txt.

Pravilo žetve: kdaj koda postane gradnik

2026-10-11T00:00:00Z

Produkt najprej v svojem repozitoriju zgradi, kar potrebuje. Vprašanje je, kdaj del te kode postane gradnik. Če kodo v gradnik prenesemo prezgodaj, načrtujemo za produkte, ki jih še ni. Če prepozno, se kopije razhajajo: isti popravek priprave Keycloaka je 10. oktobra prišel v Reputo in Leadgener z dvema zahtevama za združitev, po eno za vsako kopijo.

Dva pogoja, oba nujna

Kodo prenesemo v gradnik samo, kadar isto delovanje potrebuje tudi drugi produkt in se to delovanje ne sme razlikovati, ker gre za varnost, pravne zahteve, obratovanje ali pogodbo vmesnika API. Če drži le prvi pogoj, drugi produkt kodo prekopira in odtlej sam skrbi za svojo kopijo. Zato ogrodje aplikacije, tema za prijavo in predstavitvena stran ostajajo kopije. V šestih mesecih morata gradnik uporabljati vsaj dva produkta, sicer ga vrnemo v produkt, iz katerega izhaja.

Za produkt velja druga polovica pravila: kode gradnika ne spreminja. Pripne različico, spremembo gradnika pa naredimo v gradniku in jo izdamo kot novo različico. Za pakete NuGet ima vseh pet produktov v datoteki CI isto preverbo:

test ! -e libs/microsaas-toolkit || { echo "libs/microsaas-toolkit is back; change the toolkit in its own repository"; exit 1; }

Kako je nastal gradnik Keycloak

Reputo in Leadgener sta imela vsak svojo kopijo skripta za pripravo realma, dolgo 347 oziroma 348 vrstic. Skript nastavi, kar mora biti enako v vsakem realmu, na primer izklopljeno samoregistracijo in PKCE z metodo S256 za odjemalce v brskalniku. Kopija v Leadgenerju je nastala 8. oktobra; tri dni pozneje sta se kopiji poleg privzetih vrednosti posameznega produkta razlikovali še v komentarjih in opisu ene vloge.

Pripravo realma smo v gradnik Keycloak prenesli 11. oktobra 2026, in to zvesto: iz enakih vrednosti nastane enak realm, čiščenja kode pa v istem koraku ni bilo. Na novi namestitvi Keycloaka smo zagnali najprej skripte vsakega produkta, nato gradnik, in za vsak produkt primerjali normalizirana izvoza realma. Bila sta enaka do zadnjega bajta, razen opisa tiste vloge. To odstopanje je skupaj z razlogom zapisano v datoteki odstopanj.

Nato je vsak produkt kopijo zamenjal s svojo zahtevo za združitev. Skript se je skrčil na ovojni skript, ki vsebuje le privzete vrednosti produkta: v Reputu ima 46 vrstic, v Leadgenerju 47. Sliko gradnika ima vsak produkt pripeto na različico in povzetek (digest).

Gradnik Keycloak je torej koda, ki je že tekla v dveh produktih in je prenesena tako, da deluje enako kot tam. To dokazujejo testi, katerih rezultat pregledovalec vidi kot razliko v datotekah. Kadar gradnik ne naredi, kar potrebujete, ga ne popravljate v svojem produktu. Zaprosite za novo nastavitev, ki pride v manjši izdaji (minor) in privzeto ohrani dosedanje delovanje, to izdajo pa pripnete, ko se odločite sami. Kar potrebuje samo vaš produkt, ostane vaše.

Leadgener iz praznega repozitorija: 45 ur do razvojnega okolja

2026-10-10T00:00:00Z

Leadgener išče in spremlja poslovne priložnosti v javnih virih. Iz praznega repozitorija je začel nastajati 8. oktobra 2026; še ga gradimo, zato teče samo v razvojnem okolju. Nov produkt je mogoče presoditi šele, ko je nameščen in zaščiten z lastno prijavo.

Kopija referenčnega produkta, nova barvna paleta

Leadgenerjev ADR-02, sprejet prvi dan, določa Reputo, naš referenčni produkt, za verodostojni vir glede tehnologije, vzorcev in komponent. Spremeni se samo barvna paleta, vsako drugo odstopanje pa potrebuje svoj ADR.

Prva potrditev (commit) je vsebovala samo produktne dokumente. Deset sekund pozneje je v repozitorij prišel toolkit, kopiran brez sprememb: 167 datotek in 11.414 vrstic. Po dvanajstih minutah je sledilo ogrodje zaledja po Reputovih vzorcih, z moduli za najemnike, uvajanje in organizacije, brez obračunavanja.

Naslednjih šest ur je bilo namenjenih Leadgenerjevi domeni: zajemu objav iz javnih virov, dokumentom in slovarju ključnih besed, oceni na podlagi dokazov z izbirnim ponudnikom modela ter zaslonom za pregled rezultatov. Po 23 urah smo iz Reputa prenesli še namestitev: datoteko CI, datoteke Dockerfile, datoteko Compose in skripte za namestitev.

Kako je minilo 45 ur

Po 30 urah je nastal projekt na GitLabu; do takrat je repozitorij namenoma ostal samo lokalen.
Po 31 urah so se na veji main testi končali uspešno, nato je ukaz dotnet restore pri gradnji slik vsebnikov obstal: po desetih minutah je javil napako NU1301, pol ure pozneje pa je še vedno poskušal znova. Reputo je na isto težavo naletel 2. oktobra in jo odpravil z docker build --network host: omrežni most v Docker-in-Docker ima večji MTU kot omrežje izvajalnika (runner). Pri prenosu se je zastavica izgubila. Vrnila jo je ena zahteva za združitev, slike pa so bile zgrajene devet minut po njeni združitvi.
Po 45 urah se je zagnalo ročno opravilo deploy:dev, ki je čez noč čakalo 13,5 ure. V 1 minuti in 50 sekundah je zagnalo sedem vsebnikov, ustvarilo realm Keycloak in prestalo šest preverjanj zdravja: API-ja, aplikacije, realma, teme za prijavo in dveh predstavitvenih strani.

Za ekipo, ki na toolkitu začenja nov produkt, Leadgenerjev primer kaže približno dva dni do nameščenega razvojnega okolja, večina dela v teh dneh pa je bila namenjena samemu produktu. Še isti dan je Leadgener kopijo toolkita zamenjal s paketi NuGet, pripetimi na eno različico. Datoteka CI in skripti za namestitev so ostali preneseni iz referenčnega produkta, Leadgenerjev prvi cevovod pa kaže, koliko to stane: referenčna datoteka CI je zastavico imela, skupaj s komentarjem, ki jo pojasnjuje, pri prenosu pa sta se izgubila oba. Preden prvič potisnete v main, svoj cevovod primerjajte z referenčnim.

19 paketov, ena različica

2026-10-10T00:00:00Z

Pred izdajo 1.0.0 je imel vsak od naših petih produktov svojo kopijo skupnih modulov SaaS za najemnike, uvajanje, organizacije, pravice do funkcij, merjenje porabe, obračunavanje in skrbniški API. Kopije so bile prenesene v repozitorij vsakega produkta, najstarejša pa je za najnovejšo zaostajala približno osem mesecev. Ko smo pisali navodila za nadgradnjo na prvo izdajo, je Gostly potreboval en seznam sprememb, MojRazpis in SnapMind pa daljši. Popravek v eni kopiji je prišel do drugih le, če ga je kdo prenesel ročno.

Ena različica za vse pakete

Skupno kodo smo 10. oktobra 2026 označili z v1.0.0 in jo objavili kot 19 paketov NuGet MicroSaas.Toolkit.* z eno samo različico. Nastavitve gradnje so v eni datoteki Directory.Build.props, cevovod ob oznaki pa vsem projektom poda -p:Version=X.Y.Z, zato se tudi paketi med seboj sklicujejo na isto različico. Opravilo za objavo se ustavi, če CHANGELOG.md za to različico nima razdelka ali jo še označuje kot neizdano, in prešteje zapakirane pakete:

[ "$count" -eq 19 ] || { echo "expected 19 packages, packed $count"; exit 1; }

Register paketov je nastavljen tako, da iste različice ne sprejme dvakrat, zato 1.0.0 pomeni enako kodo v vsakem produktu.

V produktu je različica ena sama lastnost v njegovi datoteki Directory.Build.props:

<MicroSaasToolkitVersion>1.0.0</MicroSaasToolkitVersion>

Vsak PackageReference na pakete toolkita prebere to lastnost. Produkti uporabljajo različne podmnožice paketov: Leadgener 6 od 19; Reputo 16; Gostly, MojRazpis in SnapMind po 17.

Kaj to stane in česa ne pomeni

Cena je zapisana v naši zasnovi: produkt ne more prevzeti popravka v modulu Organizations brez sprememb v modulu Billing iz iste izdaje. Pri enem vzdrževalcu je eno zaporedje različic cenejše od devetnajstih, dnevnik sprememb pa to ceno pokaže vnaprej. Dnevnik vsako spremembo, ki zahteva poseg, označi z [migration], [contract] ali [behaviour] in za vsako izhodišče navede, kaj mora produkt spremeniti pred nadgradnjo.

Ena različica ne pomeni skupnih nadgradenj. Nobena izdaja ne zahteva, da se dva produkta nadgradita hkrati. Vsak produkt je na 1.0.0 prešel s svojo zahtevo za združitev (merge request) v svojem repozitoriju. Vseh pet smo združili isti dan, ker so vsi produkti opuščali svoje kopije, ne zato, ker bi to zahtevala izdaja. Produkt, ki bo želel naslednjo izdajo, jo bo prevzel s spremembo ene vrstice, ko se bo za to odločil sam.

Za ekipo, ki gradi na toolkitu, to pomeni: pripnete eno številko, pred nadgradnjo preberete razdelke dnevnika sprememb med svojo in novo različico ter se nadgradite, ko vam ustreza, ne ko ustreza nam. Če dva produkta uporabljata različni izdaji toolkita, je to povsem sprejemljivo, ker si delita kodo, nikoli pa delujoče instance.

Reputo na toolkitu: kaj je prišlo prvi dan in kaj smo zgradili sami

2026-10-02T00:00:00Z

Reputo je namenjen vodji marketinga v malem podjetju, ki svoje kampanje pošilja samostojno. V preprostem jeziku mu pove, ali e-pošta podjetja prihaja do prejemnikov, kaj je narobe in kaj naj spremenijo informatiki. Teče v razvojnem okolju, v produkciji pa še ni.

Za temi odgovori stoji večnajemniška storitev SaaS: organizacije, člani, naročniški paketi, omejitve porabe in skrbniški vmesnik za upravljavca. Za nič od tega kupec ne plača, vse pa mora delovati, preden se prijavi prva stranka.

Prvi dan: toolkit

Prva potrditev (commit) Reputa 20. septembra 2026 je vsebovala jedro za preverjanje domen, na novo zgrajeno iz prejšnjega dela, in kopijo našega toolkita v samem repozitoriju. Še isto jutro je API tekel na pravi bazi PostgreSQL in ponujal 42 poti. Štiriintrideset jih je prišlo iz toolkita, iz modulov za uvajanje, organizacije, pravice do funkcij, merjenje porabe, obračunavanje in skrbniški API. Od 12 tabel v prvi migraciji jih je bilo 11 iz toolkita.

Reputov AppDbContext je izpeljan iz razreda OrganizationDbContextBase iz toolkita, zato vsaka entiteta, ki pripada organizaciji, dobi filter po najemniku; nanj se zanašajo tudi poizvedbe po spremljanih domenah. Na strani SaaS je bila Reputova lastna koda tisti dan le povezava modulov v Program.cs, naročniški paketi Free, Pro in Business s kvotami ter kljuka (hook), ki vsaki novi organizaciji ob nastanku dodeli paket Free.

Dvanajst dni: produkt

Naslednjih dvanajst dni smo posvetili Reputovi lastni kodi okoli tega jedra: zbirnim poročilom DMARC, ki jih Reputo pobira iz poštnega predala, razčlenjenim po ponudnikih, ki so pošto prejeli; incidentom z obvestili po e-pošti v slovenščini; povezavam z Google Postmaster in Microsoft SNDS ter zaslonom. Vejo main smo prvič namestili v razvojno okolje 2. oktobra. Pri prvem poskusu se Keycloak ni zagnal; drugi, manj kot pol ure pozneje, je prestal preverjanja API-ja, aplikacije in realma Keycloak.

Za ekipo, ki na toolkitu začenja nov produkt, je pravo merilo, za kaj porabi prve tedne. V Reputu so bili najemniki, člani, pravice do funkcij, omejitve porabe in skrbniške končne točke v API vključeni že prvo jutro, dvanajst dni do razvojnega okolja pa smo porabili za preverjanja, poročila in opozorila, za katera bi plačal kupec.