Rejestracja spółki jest w toku. NIP, KRS, REGON i adres siedziby opublikujemy po wpisie. Do tego czasu administratorem korespondencji jest KoneV Software.
O NAS
Spółka startuje. Pipeline, testy i adaptery zespół składa od ponad 20 lat.
KoneV Software Sp. z o.o. jest nowym podmiotem i dopiero otwiera działalność. Osoby, które tworzą spółkę, wcześniej wchodziły do repozytoriów zleceniodawców i zostawiały tam job CI, test, kontrakt API albo adapter. Ten dorobek ma ponad 20 lat. Należy do ludzi, nie do historii spółki.
Przez ponad 20 lat praca szła w modelu wykonawcy: repo klienta, runner klienta, review klienta. Kod zostawał po zakończeniu zlecenia.
Automation Hub, TestLab, bramki jakości i zakres dedykowany zbierają tę praktykę w planach. Plan tnie funkcje, nie liczbę osób.
Co znaczy „ponad 20 lat”, a czego nie znaczy
Nie piszemy, że spółka ma 20 lat na rynku. Nie ma. Nie podajemy liczby wdrożeń, nazw zleceniodawców ani certyfikatów, których podmiot nie posiada. Podajemy rodzaj systemów, które te osoby składały, bo ten rodzaj da się sprawdzić w sposobie pracy, a nie w haśle.
W praktyce zewnętrznej powstawały cztery klasy artefaktów. Po pierwsze joby CI: szablon, obraz runtime, sekret poza repo, status czytelny dla bramki. Po drugie testy: Playwright i Selenium na ścieżkach webowych, kontrakt endpointu, PHPUnit i Jest na warstwie backendu. Po trzecie integracje: wywołanie API, zapis do bazy kontem technicznym, webhook ze statusem builda. Po czwarte adaptery tam, gdzie gotowy przebieg nie pokrywał wewnętrznego systemu zleceniodawcy.
Zlecenie kończyło się kodem w repozytorium, nie relacją, w której tylko wykonawca umie odpalić skrypt. Ta zasada przechodzi do oferty spółki. Opis uruchomienia, lista sekretów i właściciel katalogu zostają przy kodzie.
Jak ta praktyka wyglądała operacyjnie
Wejście w zlecenie zaczynało się od odczytu pipeline, nie od propozycji wymiany narzędzi. Runner, który już budował produkt, dostawał nowy job. Język skryptu wynikał z repo. Jeśli zespół pisał w PHP, test backendu szedł w PHPUnit. Jeśli warstwa frontu miała runner JavaScript, zestaw szedł w Jest albo w Playwright, zależnie od tego, czy sprawdzano jednostkę, czy przeglądarkę.
Sekret nie wchodził do historii gita. Konto do bazy było kontem operacji, nie kontem administratora. Log joba dostawał kod wyjścia i identyfikator przebiegu. Treść, która nie była potrzebna do diagnozy, nie była dopisywana „na zapas”. Test niestabilny schodził z bramki do kwarantanny, zamiast uczyć zespół klikania ponownego przebiegu aż do zielonego słupka.
Review należał do zleceniodawcy. Wykonawca nie mergował z pominięciem reguł brancha. Wyjątek od bramki miał autora i powód. To są nawyki z długiej praktyki. Spółka zapisuje je teraz jako opis planów: generator, biblioteka, szablon CI, generator testów, godziny inżyniera, SSO i dedykowany runtime.
Co spółka robi teraz
KoneV Software uruchamia własną platformę i własną siatkę planów. Automation Hub produktuje generator, bibliotekę i integracje. TestLab produktuje trzy klasy testów w jobie. Inżynieria jakości ustawia bramkę, próg i właściciela katalogu. Rozwiązania dedykowane zostają przy adapterze, konektorze i środowisku Enterprise, gdy szablon nie wystarcza.
Jednocześnie spółka jest na starcie działalności. Nie ma jeszcze opublikowanego numeru KRS. Nie prowadzi biura, którego adres można wpisać w stopkę. Nie powołuje inspektora ochrony danych, dopóki skala przetwarzania tego nie wymaga. Te braki są wpisane w politykę prywatności i na stronie RODO, a nie schowane pod ogólnym „jesteśmy nowocześni”.
Oferta nie jest obietnicą, że model językowy zastąpi review. Generator składa szkic skryptu albo szkic testu. Szkic przechodzi ten sam przegląd co reszta zmian. Model jest warstwą, która skraca pierwszy zapis pliku. Bramka, kontrakt i właściciel kodu zostają.
Zasady, których nie obchodzimy w planie
- Artefakt ląduje w repozytorium klienta albo w bibliotece planu, z wersją.
- Sekret jest referencją w szablonie joba. Wartość zostaje w magazynie CI.
- Test czyta fixture syntetyczny. Dane produkcyjne osób wymagają umowy powierzenia i osobnej decyzji, czy w ogóle są potrzebne.
- Czerwony raport blokuje merge. Ręczne odznaczenie statusu nie jest definicją zielonego builda.
- Zakres planu jest listą funkcji. Nie doliczamy opłaty od osoby, która odpala job.
- Nie publikujemy nazw zleceniodawców z okresu usługi zewnętrznej. Ich repozytoria nie są portfolio spółki.
Dla kogo jest ten przebieg
Dla zespołu, który ma repozytorium i system CI oraz chce dołożyć skrypt, test albo adapter bez budowania tej warstwy od pustego katalogu. Rozmowa zaczyna się od obiektów: język, runner, endpoint, którego kontrakt jest niestabilny, job, którego brakuje na bramce. Nie zaczyna się od liczby stanowisk.
Indywidualny programista może wejść w plan Developer: generator i biblioteka. Zespół z API i testami wchodzi w plan Team albo wyżej. Organizacja, która potrzebuje SSO i osobnego runtime, wchodzi w Enterprise i dostaje warunki w umowie, nie w domyślnym cenniku.
Jak startuje współpraca
Strona nie ma formularza. Wiadomość e-mail wystarcza. W treści: repo albo jego charakter, system CI, runtime, artefakt, który ma powstać, i czy w przebiegu mogą pojawić się dane osobowe. Na tej podstawie wraca propozycja planu albo zakres dedykowany. Hasła i klucze API nie są potrzebne na tym etapie. Zasada minimalizacji wynika z art. 5 ust. 1 lit. c RODO i jest powtórzona na stronie kontaktu.