AUTOMATION HUB
Automation Hub jest warstwą nad repozytorium i systemem CI, którego zespół już używa. Nie wynosi automatyzacji do osobnego miejsca bez historii zmian. Skrypt, szablon i opis wejścia zostają w repo, obok kodu, który ten skrypt obsługuje.
Wejściem jest opis zadania: cel, język, ograniczenia efektów ubocznych, przykład wejścia i przykład wyjścia. Wyjściem jest skrypt, który da się odpalić lokalnie i w jobie. Język wynika z repo i z planu, nie z domyślnego szablonu marketingowego.
Skrypt woła endpoint HTTP, kolejkę albo bazę. Schema żądania i odpowiedzi jest opisana obok skryptu. Błąd API nie kończy się ciszą: job zapisuje kod statusu, identyfikator przebiegu i fragment logu bez sekretów.
Powtarzalne skrypty wchodzą do prywatnej biblioteki zespołu. Wersja biblioteki jest wersją w repo. Szablon firmowy da się podmienić w jednym miejscu, zamiast kopiować plik między projektami i gubić poprawkę.
Szablon joba wskazuje obraz runtime, katalog skryptu i sekret z magazynu CI. Docker jest sposobem na powtarzalny runtime, nie osobnym produktem. Po zakończeniu job może wysłać webhook.
Czego w repo nie ma: haseł, tokenów, kluczy API, zrzutów produkcyjnych baz. Sekret jest referencją. Wartość zostaje w magazynie CI albo w sejfie sekretów organizacji.
Autor wskazuje runtime, źródło danych i warunek stopu. Bez tego generator nie uzupełnia kontraktu wejścia domysłem. Brakujący opis wraca jako pytanie, nie jako wpis w kodzie.
Plik przechodzi ten sam przegląd co reszta zmian w repo. Generator przyspiesza pierwszy szkic. Nie omija review i nie merguje sam.
Pipeline uruchamia skrypt na zmianie. Log pokazuje komendę, obraz, czas i kod wyjścia. Czerwony job zostaje czerwony. Nie ma ręcznego „odznacz, że przeszło”.
Gdy plan obejmuje integracje, endpoint dostaje identyfikator builda, status i adres logu. Payload nie zawiera sekretu ani treści, która nie jest potrzebna odbiorcy.
Automatyzacja API, dostępna od planu Team, składa wywołanie według schematu: metoda, ścieżka, nagłówki bez sekretu w pliku, ciało, oczekiwany status. Powtarzalny przebieg może złożyć kilka wywołań w kolejności, z warunkiem przerwania po błędzie. Zapis do bazy idzie przez zapytanie opisane w skrypcie i przez konto techniczne o uprawnieniach wyciętych do tej operacji, nie przez konto administratora wklejone do zmiennej.
Jeżeli endpoint nie ma stabilnego kontraktu, najpierw powstaje opis kontraktu i test kontraktu w TestLab. Hub nie owija niestabilnego API kolejną warstwą retry bez limitu. Retry, timeout i idempotencja są parametrami skryptu, widocznymi w repo.
Plan Developer obejmuje generator, wybrane runtime i prywatną bibliotekę, z limitem przetwarzania tego planu. Team dokłada automatyzację API, generator testów i szablony CI oraz wyższy limit. Business otwiera pełny zestaw funkcji huba, firmowe szablony i 2 godziny pracy inżyniera KoneV w miesiącu. Business Pro dokłada integrację z repozytorium Git, orkiestrację przebiegów, priorytet kolejki i rozszerzony log audytowy oraz 5 godzin pracy inżyniera. Enterprise opisuje dedykowany runtime, SSO i warunki poza siatką planów.
Żaden plan nie sprzedaje „nielimitowanych użytkowników”. Ograniczeniem jest zakres funkcji, limit przetwarzania i liczba godzin inżyniera wpisana w plan. Kto w zespole uruchamia job, wynika z uprawnień w repo i w CI klienta.
Praktyka, na której hub stoi, pochodzi z ponad 20 lat składania takich przebiegów jako usługa zewnętrzna. Spółka KoneV Software tę praktykę dopiero produktuje. Historia osób i status spółki są opisane na stronie o nas.