A Product Printer mögötti elmélet
A szoftver már nem mesterség. Hanem egy technika.
Hetven éven át a szoftvert úgy készítették, mint a bútort a műhelyben — egy mester, egy darab, mindent a nulláról. Ez a korszak véget ért. Ha a kódírás olcsóvá válik, az érték a tervbe, az alkatrészekbe és a gyártósorba kerül. Ezért gyárként építkezünk.
A mesterségtől a technikáig
A kódírás költsége összeomlott
Az MI-ügynökök ma a kód nagy részét megírják. Minden szoftverprojekt drága középső szakasza — a megvalósítás begépelése — szinte egyik napról a másikra olcsóvá vált. Célunk: amihez egy csapatnak korábban egy negyedév kellett, azt a felügyelt gyártósor egy hét alatt szállítja.
A legtöbb szoftver megoldott probléma
Bejelentkezés, számlázás, többbérlős működés, nyelvek, monitorozás: minden üzleti alkalmazásnak szüksége van rájuk, és egyiket sem érdemes újra feltalálni. Ezek szabványos alkatrészek — katalógustételek, nem tervezési munka.
Ami szűkös marad, az maga a probléma
Egy kerékpárbolt, egy bérelt járműflotta, egy gondozási szolgáltatás megértése — és annak pontos meghatározása, mit érdemes építeni. Ez az a terület, ahol az embereknek a helyük. Minden, ami egy jó specifikáció után következik, iparosítható.
A mesterség technikává válik abban a pillanatban, amikor a lépései leírhatók, megismételhetők és ellenőrizhetők. A szoftver épp átlépte ezt a határt — és ha valami technika, a gyár legyőzi a műhelyt.
A sor, állomásról állomásra
Az első képzéstől a működő szoftverig, állomásról állomásra. Mindegyik meg van jelölve: az Élő már ma fut; a Hamarosan az, amit következőként építünk.
01Élő
Az egész képzéssel indul
A sor előtt az emberek jönnek: a tanácsadók megtanulnak AI-ról tanácsot adni kkv-knak, majd saját márkanévvel használható tanfolyammal képzik ügyfeleik csapatait. A tanfolyam utolsó lépése új projekt vagy új követelmények lesz.
Bővebben02Élő
Először a követelmények
Homályos megbízásból semmi nem épül. Egy beszélgetésből követelmények lesznek, mindegyik elfogadási kritériumokkal, és a sor csak az elfogadott dolgokat építi meg.
03Élő
Folyamatos sor
Amint a követelményeket elfogadták, egy munkalépés kattintás nélkül kerül kódolóügynökhöz: projektenként egyszerre egy építés, sorrendben. Minden munkalépés pull requestként távozik.
04Élő
Kapuk minden változtatásnál
Minden pull request átmegy a projekt CI- és biztonsági vizsgálatain, majd egy AI-alapú biztonsági felülvizsgálaton, amely hibás állapotban zár: ítélet nélkül nincs összefésülés, és az összefésülés a felülvizsgált pontos verzióhoz van kötve. A főágon őrszem akadályozza meg, hogy a kapukat megkerülő változtatás élesbe kerüljön.
05Élő
Bizonyíték kritériumonként
Minden elfogadási kritérium saját tesztfuttatást kap a CI-ből, amely a követelmény utolsó módosításának egyesítése után kerül rögzítésre, és egy követelmény csak akkor minősül ellenőrzöttnek, ha mindegyik sikeres. Egy ember által ellenőrzött kritérium „Függőben lévő emberi ellenőrzés” állapotot mutat, amíg jóvá nem hagyják. Az ügynök szava sosem számít.
06Élő
Először a teszt, pirosból zöldbe
Minden elfogadási kritérium tesztje először kerül megírásra, saját commitban, és a CI-ben sikertelennek kell lennie, mielőtt a kód sikeresvé tenné. A módosítás egyesítése előtt a kapu ellenőrzi, hogy minden kritérium tesztje pirosról zöldre váltott-e, és nem változott-e közben; a követelmény mindkét futtatást összekapcsolja.
07Élő
Javítási ciklus
Ha a CI vagy a biztonsági felülvizsgálat visszautasít egy változtatást, a megállapítások ugyanahhoz az ügynöki munkamenethez kerülnek vissza, amely ugyanazon a pull requesten javítja őket, és minden kapu újra lefut. Alapértelmezés szerint legfeljebb két javítás van; utána egy ember veszi át.
08Élő
Szabványos elemek
Minden alkalmazás a gyári sablonból indul, a már megoldott részekkel: bejelentkezés, bérlők és szerepkörök, jogi oldalak, elrendezés. Egyszer épül, élesben megerősítjük, és soha nem építjük újra.
09Élő
A gyári könyvtár minden lépésnél
Amikor egy munkalépés-tervet jóváhagynak, minden munkalépéshez csatolva vannak a tervezés által választott szabványos elemek. Az adatbázist vagy más érzékeny területeket érintő munkalépéseket a könyvtár biztonsági és adatbázis-irányelveivel építik, az építési jegyzőkönyv pedig felsorolja, melyek és miért.
10Élő
Kiadás élesbe
Egy kiadás közzététele egy üzemeltetett alkalmazást juttat élesbe: előbb az adatbázis-migrációk, sorrendben, az első hibánál megállva; utána az építés. A kiadás csak akkor mutatja az Élő állapotot, ha az élő cím már ezt szolgálja ki.
11Élő
Őszinte állapot
Amíg a hatókörbe tartozó minden elem ki nincs adva, a projekt így jelenik meg: „Épül — 6 munkalépésből 3 kiadva”, és csak ezután „Élő”. Egy új alkalmazás látogatóinak a „Hamarosan” felirat jelenik meg, a bejelentkezett felhasználóknak pedig az építési lépések. Az „Mi van az alkalmazásban” oldal felsorolja a kapott elemeket, azt, ami már elkészült, és azt, ami még hátravan.
12Élő
Nyilvántartásban
Minden építési feladat, minden kiadási telepítés és minden olyan változtatás, amely a kapukon kívül jutott a főágba, rögzítésre kerül. Üzemeltetői műveleteink egy csak hozzáfűzhető naplóba kerülnek.
13Élő
Hatókörhöz kötött kulcsok, EU-s tárhely
Az általunk üzemeltetett alkalmazásoknál minden építés rövid életű, csak arra az egy tárolóra érvényes tokent kap, amely az építés végén megsemmisül. Az Ön modellkulcsai az Ön PP Orchestratoránál maradnak. A felhőpéldányok Németországban (EU) futnak.
Az „Élő” azt jelenti, hogy a Product Printer egy kiadásában már szállítjuk, és a felügyelt példányainkon fut. Egy állomás csak akkor vált Hamarosanból Élővé, amikor a hozzá tartozó kiadás megjelent.
A műhelykorszak szép volt. A gyárkorszak megfizethető.
— Szűrjük ki a zajt.
Jöjjön a problémájával →