Teoria stojąca za Product Printer
Oprogramowanie nie jest już rzemiosłem. To technika.
Przez siedemdziesiąt lat oprogramowanie powstawało jak meble w warsztacie — jeden rzemieślnik, jeden egzemplarz, wszystko od zera. Ta epoka właśnie się skończyła. Gdy pisanie kodu staje się tanie, wartość przenosi się na plan, części i linię produkcyjną. Dlatego budujemy jak fabryka.
Od rzemiosła do techniki
Koszt pisania kodu spadł
Agenci AI piszą dziś większość kodu. Kosztowny środek każdego projektu programistycznego — wpisywanie implementacji — niemal z dnia na dzień stał się tanią częścią. Nasz cel: to, co dotąd zajmowało zespołowi kwartał, nadzorowana linia produkcyjna dostarcza w tydzień.
Większość oprogramowania to problem rozwiązany
Logowanie, rozliczenia, wielodostępność, języki, monitoring: każda aplikacja biznesowa tego potrzebuje, a żadnego z tych elementów nie warto wymyślać od nowa. To standardowe części — pozycje katalogowe, a nie praca projektowa.
Rzadkie pozostaje samo zadanie
Zrozumienie sklepu rowerowego, floty wypożyczalni czy usługi opiekuńczej — i precyzyjne określenie, co należy zbudować. Tu jest miejsce dla ludzi. Wszystko, co następuje po dobrej specyfikacji, można uprzemysłowić.
Rzemiosło staje się techniką w chwili, gdy jego kroki można spisać, powtarzać i sprawdzać. Oprogramowanie właśnie przekroczyło tę granicę — a gdy coś jest techniką, fabryka bije warsztat.
Linia, stacja po stacji
Od pierwszego szkolenia po działające oprogramowanie, stacja po stacji. Każda jest oznaczona: „Działa” oznacza funkcję dostępną już dziś, „Wkrótce” to to, co budujemy jako następne.
01Działa
Zaczyna się od szkolenia
Przed linią są ludzie: doradcy uczą się doradzać MŚP w zakresie AI, a następnie szkolą zespoły swoich klientów na kursie w białej etykiecie, którego ostatni krok staje się nowym projektem lub nowymi wymaganiami.
Dowiedz się więcej02Działa
Najpierw wymagania
Nic nie powstaje na podstawie niejasnego zlecenia. Rozmowa staje się wymaganiami, a każde z nich ma własne kryteria akceptacji. Linia buduje wyłącznie to, co zostało zaakceptowane.
03Działa
Ciągła linia
Gdy tylko jego wymagania zostaną zaakceptowane, etap pracy trafia do agenta kodującego bez dodatkowego kliknięcia: jedna budowa naraz na projekt, w kolejności. Każdy etap kończy się pull requestem.
04Działa
Bramki przy każdej zmianie
Każdy pull request przechodzi przez CI projektu i skanowanie bezpieczeństwa, a następnie przez przegląd bezpieczeństwa AI, który działa w trybie fail-closed: brak werdyktu oznacza brak scalenia, a scalenie jest przypięte do dokładnie przejrzanej wersji. Zabezpieczenie gałęzi głównej nie pozwala wdrożyć niczego, co ominęło bramki.
05Działa
Dowód dla każdego kryterium
Każde kryterium akceptacji otrzymuje własny przebieg testu z CI, rejestrowany po scaleniu ostatniej zmiany w wymaganiu, a wymaganie jest uznawane za zweryfikowane dopiero wtedy, gdy wszystkie z nich przejdą pomyślnie. Kryterium sprawdzane przez człowieka wyświetla „Oczekiwanie na sprawdzenie przez człowieka”, dopóki nie zostanie zatwierdzone. Słowo agenta nigdy nie jest brane pod uwagę.
06Działa
Najpierw test, od czerwonego do zielonego
Test dla każdego kryterium akceptacji jest pisany jako pierwszy, w osobnym commicie, i musi zakończyć się niepowodzeniem w CI, zanim kod sprawi, że przejdzie. Przed scaleniem zmiany bramka sprawdza, czy test każdego kryterium zmienił się z czerwonego na zielony i nie został po drodze zmieniony; wymaganie łączy oba przebiegi.
07Działa
Pętla napraw
Gdy CI lub przegląd bezpieczeństwa odrzuci zmianę, uwagi wracają do tej samej sesji agenta, który naprawia je w tym samym pull requeście, a każda bramka uruchamia się ponownie. Domyślnie są maksymalnie dwie naprawy; potem przejmuje człowiek.
08Działa
Standardowe części
Każda aplikacja startuje z szablonu fabryki, z już wbudowanymi rozwiązanymi problemami: logowaniem, najemcami i rolami, stronami prawnymi, układem. Zbudowane raz, utwardzone w produkcji, nigdy nie budowane od nowa.
09Działa
Biblioteka fabryki na każdym kroku
Gdy plan etapu pracy zostanie zatwierdzony, każdy etap zawiera standardowe części wybrane w projekcie. Etapy dotykające bazy danych lub innych wrażliwych obszarów są budowane zgodnie z wytycznymi bezpieczeństwa i baz danych z biblioteki, a rejestr budowy wskazuje, które wytyczne zastosowano i dlaczego.
10Działa
Wydanie na żywo
Opublikowanie wydania wdraża hostowaną aplikację na produkcję: najpierw migracje bazy danych, po kolei, zatrzymując się na pierwszym błędzie, potem budowa. Wydanie pokazuje status „Działa” dopiero wtedy, gdy pod żywym adresem jest już serwowane.
11Działa
Uczciwy stan
Dopóki wszystko w zakresie nie zostanie wydane, projekt pokazuje „W budowie — wdrożono 3 z 6 etapów”, a „Działa” dopiero po tym. Nowa aplikacja wyświetla odwiedzającym „Wkrótce” i pokazuje zalogowanym użytkownikom kroki budowy. Strona „Co jest w aplikacji” wymienia części, z których powstała, to, co zostało zbudowane, i to, co jeszcze przed nami.
12Działa
Zapisane w rejestrze
Każde zadanie budowy, każde wdrożenie wydania i każda zmiana, która trafiła do gałęzi głównej z pominięciem bramek, są rejestrowane. Działania naszych operatorów trafiają do dziennika audytu, do którego można tylko dopisywać.
13Działa
Klucze o ograniczonym zakresie, hosting w UE
Dla aplikacji, które hostujemy, każda budowa dostaje krótkotrwały token tylko do jednego repozytorium, usuwany po zakończeniu budowy. Państwa klucze do modeli pozostają w Państwa PP Orchestratorze. Instancje w chmurze działają w Niemczech (UE).
„Działa” oznacza, że funkcja została dostarczona w wydaniu Product Printer i działa na naszych zarządzanych instancjach. Stacja przechodzi ze statusu „Wkrótce” do „Działa” dopiero wtedy, gdy jej wydanie jest już dostępne.
Epoka warsztatu była piękna. Epoka fabryki jest dostępna cenowo.
— Eliminujemy szum.
Przyjdź z własnym problemem →