Usługi / Wsparcie software house
Software houseProjektujemy i utrzymujemy platformę DevOps pod projekty Waszych klientów
Projektujemy, wdrażamy i utrzymujemy platformę dostarczania pod projekty Waszych klientów. Zaczynamy od Waszego sposobu pracy: repozytoria, środowiska, kto wdraża i jak wygląda umowa z klientem. Potem stawiamy szablon pipeline, izolację w Kubernetes i Argo CD. Zostajemy przy dyżurze, SLO i showback per projekt.
Jak to składa się w całość
Od projektów klientów do pipeline, izolacji i dyżuru
Najpierw rozumiemy, jak dostarczacie produkt i jak wygląda umowa z klientem. Na tej podstawie składamy CI, GitOps, izolację i obserwowalność w warstwę pod delivery. GitLab, GitHub Actions, Argo CD i Grafana służą do tej pracy na co dzień.
- Trzymamy infrastrukturę pod Waszym delivery. Backlog produktowy zostaje u Was.
- Model retainer albo per projekt, z jasnym podziałem, kto bierze P1 aplikacji.
Budujemy szablon pipeline, który zespół kopiuje na nowy projekt
Składamy jeden harness: test, skan, obraz, preview. Nowy klient dostaje ten sam szablon, z inną konfiguracją. Runner i registry są Wasze albo nasze, z izolacją i kosztem per projekt.
Szablon
Repo starter, environments, sekrety, polityka branchy.
Preview
Merge request wstaje na izolowanej przestrzeni i znika. Klient widzi build.
Skan
Zależności i obraz w pipeline. Znalezisko idzie do backlogu projektu.
Billing
Minuty CI i registry da się przypisać do klienta.
Wdrażamy ten sam poziom bramek, gdy zespół pracuje na GitHubie
Gdy zespół żyje na GitHubie, ops nie wymaga migracji. Ten sam poziom bramek i OIDC do chmury. Workflow per szablon. Actions na kubernetes/kubernetes to wzorzec skali, u Was schodzimy do tego, co zespół utrzyma.
OIDC
Rola per środowisko, bez długowiecznego klucza w secrets.
Macierz
Klient A nie widzi sekretów klienta B. Osobne environment protections.
Cache
Szybszy build bez wycieku artefaktów między tenantami.
Ślad
Kto zatwierdził deploy na produkcję klienta.
Stawiamy środowisko per klient, z osobnym projektem
ApplicationSet albo szablon projektu. Namespace, quota, sieć. Klient nie siedzi na wspólnym cluster-admin. Sync i health widać bez wchodzenia na Wasz kanał poza godzinami biura.
Izolacja
RBAC, NetworkPolicy, osobne sekrety. Blast radius jednego projektu.
Szablon
Nowe środowisko wstaje z merge. kubectl zostaje narzędziem diagnozy.
Promocja
Stage klienta, potem produkcja. Ta sama ścieżka co u Was w środku.
Offboarding
Retencja danych i kasowanie namespace są w liście kontrolnej umowy.
Utrzymujemy dyżur i SLO, które da się wpisać w umowę
Dashboard per tenant albo folder. Alert idzie do nas, z eskalacją do Was gdy aplikacja. Raport dostępności wchodzi do umowy. Nocną zmianę na infrastrukturę bierzemy w zakres.
SLO
p95 i błąd per usługa klienta. Budżet zapisany.
Dyżur
P1 na infrastrukturę. P2 na aplikację według umowy.
Koszt
Showback per projekt. Klient widzi, za co płaci w chmurze.
Handover
Gdy projekt schodzi, dokumentacja i IaC zostają w repozytorium.
Jak pracujemy
Od projektów Waszych klientów do dyżuru
Zaczynamy od Waszego sposobu delivery. Potem stawiamy katalog środowisk i izolację. Wdrażamy pierwszy projekt na szablonie. Zostajemy przy dyżurze, SLA i showback.
- Szablon Sprawdzamy pipeline, chart, sekrety, sieć i quota. Składamy starter, z którego wstaje nowy projekt.
- Onboarding Stawiamy pierwszy projekt klienta na szablonie. Izolacja, billing i preview są w zakresie od startu.
- Rytm Upgrade platformy, skan i przegląd tenanta wchodzą do kalendarza. Nowy klient kopiuje ten sam harness.
- Umowa Zapisujemy SLA, eskalację, offboarding i raport. Dyżur da się wpisać w umowę z klientem.
Rozmowa
Omówimy projekty, szablon środowisk i SLA
Na tej podstawie przygotujemy zakres: pipeline, izolacja, GitOps i dyżur.
Skontaktuj się