Usługi / Wsparcie software house

Dla agencji i software house’ów

Platforma per klient, bez budowania własnego opsu

GitLab albo GitHub Actions na delivery. Argo CD na środowiska klientów. Kubernetes z izolacją. Grafana i dyżur poza godzinami biura. Wy dostarczacie produkt, my warstwę, którą da się wpisać w umowę z klientem.

Szablon Nowe środowisko z katalogu, nie od zera
Izolacja IAM, sieć i billing per klient
Preview MR z żywym środowiskiem
SLA Dyżur, który da się wpisać w umowę
Jak to składa się w całość

Delivery, tenanci, dyżur

Software house bez platformy powtarza ten sam ops przy każdym kliencie. Składamy CI, GitOps, izolację i obserwowalność w warstwę, którą sprzedajecie obok produktu.

  • Nie wchodzimy w Wasz backlog produktowy. Trzymamy infrastrukturę pod nim.
  • Model retainer albo per projekt, z jasnym podziałem, kto bierze P1 aplikacji.
GitLab, pipeline CI/CD, status i etapy build
01, CI/CD

Szablon pipeline, który zespół kopiuje na nowy projekt

Jeden harness: test, skan, obraz, preview. Nowy klient nie zaczyna od pustego YAML. Runner i registry są Wasze albo nasze, z izolacją i kosztem per projekt.

Szablon

Repo starter, environments, sekrety, polityka branchy.

Preview

MR wstaje na izolowanej przestrzeni i znika. Klient widzi build, nie Wasz laptop.

Skan

Zależności i obraz w pipeline. Znalezisko idzie do backlogu projektu.

Billing

Minuty CI i registry da się przypisać do klienta.

GitHub Actions, przebiegi workflow i status jobów
02, GitHub Actions

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

Bez długowiecznego klucza w secrets. Rola per środowisko.

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.

Argo CD, aplikacje, health i sync GitOps
03, Argo CD

Ś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 Slack o 23.

Izolacja

RBAC, NetworkPolicy, osobne sekrety. Blast radius jednego projektu.

Szablon

Nowe środowisko z merge, nie z weekendową sesją kubectl.

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.

Grafana, katalog dashboardów i źródeł danych
04, Grafana

Dyżur i SLO, które da się sprzedać

Dashboard per tenant albo folder. Alert idzie do nas, z eskalacją do Was gdy aplikacja. Raport dostępności do umowy. Nie budujecie nocnej zmiany od zera.

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ą, nie lore w głowie.

Operacja

Od szablonu do opieki nad tenantem

Najpierw Wasz sposób delivery. Potem katalog środowisk. Na końcu dyżur i showback.

  1. Szablon Pipeline, chart, sekrety, sieć, quota.
  2. Onboarding Pierwszy klient na szablonie, izolacja, billing.
  3. Rytm Upgrade platformy, skan, przegląd tenanta.
  4. Umowa SLA, eskalacja, offboarding, raport.
Rozmowa

Omówimy szablon środowisk i SLA

Na tej podstawie przygotujemy warstwę platformy pod Wasze delivery.

Skontaktuj się