დეველოპერების შიდა ინსტრუმენტები

1) დეველოპერის პლატფორმის როლი და პასუხისმგებლობის არეალი (IDP)

• სწრაფი დაწყება (მომსახურების შაბლონები, API ჩონჩხი, paplines);
• პროგნოზირებადი შეკრება/ტესტირება/გამონაყარი;
• უსაფრთხო საიდუმლოების, დამოკიდებულებებისა და არტეფაქტების მართვა;
• ნაგულისხმევი დაკვირვება (ლოგოები/მეტრიკა/ტრეისი);
• პროვაიდერების ტესტის მონაცემებზე წვდომა, პარკები და ქვიშის ყუთები;
• დოკუმენტაცია და ოქროს ბილიკები სტანდარტული სცენარებისთვის.

მიზანია შეამციროს შემეცნებითი დატვირთვა, დრო-პირველი-PR და Lead Time for Changes, გაზარდოს გამოშვებების საიმედოობა და შესაბამისობა.

2) DX დიზაინის პრინციპები (Developer eXperience)

Convention over configuration: სტანდარტები უფრო მნიშვნელოვანია, ვიდრე სახელმძღვანელო პარამეტრები.
Golden Paths: ნაგულისხმევი გადაწყვეტილებების მინიმალური ნაკრები, რომელიც მოიცავს შემთხვევების 80% -ს.
Everything as Code: დალაგება, ინფრასტრუქტურა, დაშბორდები, პოლიტიკოსები - Git- ში.
Secure-by-default: SAST/DAST, SBOM, არტეფაქტების ხელმოწერა, დამოკიდებულების პოლიტიკა.
Observability-first: სერვისები და ინსტრუმენტები ავტომატურად ასხივებენ ტელემეტრიას.
გარემოცვის პორტაბელურობა: ადგილობრივად = CI = stage = prod (რამდენადაც შესაძლებელია).
უკუკავშირი წუთებში: სწრაფი ტესტები, ლინტები, წინასწარი გარემო, PR სტატუსები.

3) პლატფორმის არქიტექტურა და ძირითადი კომპონენტები

DevPortal: სერვისების კატალოგი, შაბლონები, დოკუმენტაცია, პლატფორმის სტატუსი, „one-click“ payplines და გარემო.
CLI/ჩონჩხი: სერვისების/ფუნქციების/ჯობების წარმოება ერთი დასტის საშუალებით (ლოგიკა, ჯანმრთელობის დაცვა, OpenAPI/Proto, observability).
ბილდის სისტემა და ერთფეროვანი ინსტრუმენტები: ქეშირება, სავარაუდო შეკრება, დეტერმინისტული არტეფაქტები.
CI/CD bluprints: სტანდარტული პაკეტები მომსახურებისთვის (ერთეული, კონტრაქტები, ინტეგრაცია, e2e, უსაფრთხოების ანალიზი, გამონაყარი).
ტესტის კონტურები: ტესტის კონტეინერები/პროვაიდერების ადგილობრივი ქვიშის ყუთები, მონაცემთა საერთო ქარხანა და ფიტინგები.
„ყუთიდან“ დაკვირვება: OTel/Prometheus/logger კავშირი ერთი მოდულის საშუალებით.
საიდუმლო მენეჯმენტი: ინტეგრაცია KMS/HSM- სთან, როტაცია, დაშვების პოლიტიკა.
ფიჩეფლაგები/ექსპერიმენტები: SDK და კონსოლი პროგრესული დრაივებისთვის.

4) DevPortal: ცენტრალური შესასვლელი წერტილი

• სერვისების/ბიბლიოთეკების/სქემების კატალოგი (owner, SLA, ვერსიები, დაუცველები);
• ღილაკი „შექმენით სერვისი“ შაბლონის მიხედვით (დაუყოვნებლივ დალუქვით და ალერტებით);
• დოკუმენტაცია (კოდი სტილის სტანდარტები, გამოშვებების ჰიტები, ინციდენტების ფლეიბუკები);
• პლატფორმის სერვისების სტატუსი, კაპიტალი, ცვლილებები (changelog);
• Runbooks და Golden Paths: „როგორ დაამატოთ ენდოინტი“, „როგორ დაიწყოთ მიგრაცია“, „როგორ დააკავშიროთ პროვაიდერი“.

5) CLI და შაბლონები (ჩონჩხი)

• REST/gRPC/GraphQL სერვისის ჩარჩო health ჩეკებით ,/metrics ,/ready;
• მზა middlewares: მოთხოვნის კორელაცია, ავთენტიფიკაცია, rate limits;
• OpenAPI/Protobuf + ავტოგენი სქემების შემოწმება CI- ზე;
• მოდულური ლოგერი, ტრეისი, მეტრიკა;
• dockerfile + კომპოზიცია ადგილობრივი განვითარებისთვის;
• ტესტების ძირითადი ნაკრები და ლინტერების კონფიგურაცია/formatters/prehucks.

• `devx new service --name payments-api --stack go-grpc --db postgres --events kafka --template v2`

6) ადგილობრივი განვითარება და დისტანციური გარემო

Dev Containers/Codespaces ანალოგი: ყველას აქვს იგივე გარემო, სწრაფი ონბორდი.
Docker Compose + Testcontainers: BD/ქეში/საბურავები ადგილობრივად ერთი გუნდის მიერ იზრდება.
Tilt/Skaffold ცოცხალი გადატვირთვისთვის Kubernetes კლასტერში „dev“.
Remote Dev: რესურსის ინტენსიური შეკრება/ტესტები ხორციელდება გამოყოფილი აუზებზე.

სასარგებლო პრაქტიკა

ერთი '.tool ვერსიები '/lockfiles ინსტრუმენტების ვერსიებისთვის;

make/just-скрипты: `make test`, `make run-local`, `make seed`;

ადგილობრივი საიდუმლოებები 'dotenv- ის მეშვეობით და საიდუმლოებების პროვაიდერი dev როლებით.

7) სქემებისა და კონტრაქტების მართვა

Schema Registry (JSON/Avro/Proto) თავსებადობის პოლიტიკასთან;

Contract testing (Pact/Buf), როგორც სავალდებულო ჯობი CI- ზე;

ვერსია API (SemVer), ორმაგი ვერსიის მხარდაჭერა, ავტომატური SDK წარმოება;

BD მიგრაცია (migrate/flyway/liquibase) არის სტანდარტიზებული pypline ნაბიჯი.

8) ტესტის პირამიდა და მონაცემები

ერთეულის ტესტები: სწრაფი, პარალელური, კრიტიკული ლოგიკის დაფარვის ვალდებულება.
კონტრაქტის ტესტები: მომხმარებელი - API/მოვლენების პროვაიდერი.
ინტეგრაცია: კონტეინერებში რეალური დამოკიდებულებით.
E2E: „მონახაზების“ მინიმალური, მაგრამ წარმომადგენლობითი ნაკრები.
ტესტის მონაცემები: ქარხნები/ფიქსატორები, სინთეტიკა PII- ის გარეშე, გარემოსთვის სიდრები; BD Snaphots მხოლოდ ანონიმურია.

9) CI/CD: სტანდარტიზაცია

1. Lint/Format/License/SBOM წარმოება.

2. SAST (სტატიკური ანალიზი) + დამოკიდებულების პოლიტიკა, რომელიც ბლოკავს „კრიტიკას“.

3. Unit - Contracts - Integration - E2E არტეფაქტებითა და მოხსენებებით.

4. დეტერმინისტული გამოსახულების build, ხელმოწერა (sigstore/cosign), push in registry.

• feature-env/preview URL თითოეული PR;
• canary/blue-green stage;
• პროგრესული პროდუქტიული გამოშვება ძაფის/ტრაფიკის საშუალებით;

6. Post-deploy checks: ალერტები, error budget, მანქანის ხრახნი დეგრადაციის დროს.

10) დაკვირვება და ადგილობრივი დრიფტი

მოდული „telemetry-starter“: მოიცავს OTel SDK, ექსპორტიორებს, კორელაციას „trace _ id“;

Dashboards as Code: დაშბორდები და ალერტები აღწერილია Git- ში;

Trace-driven dev: მოთხოვნის პროფილირება ადგილობრივად და წინასწარ სტენდებში;

სტრუქტურირებული ლოგოები (JSON), დაცვა PII- სგან, მგრძნობიარე ველების შენიღბვა.

11) კოდისა და შურისძიების ხარისხი

ერთი საბრძოლო ხომალდი/ფორმატერი და პრესეტა (სპეციფიკური ენა);

pre commit hukes (მცირე ზომის ლინთები/ტესტები);

Code Owners და სავალდებულო მიმოხილვები ძირითადი არტეფაქტებისთვის (სქემები, მიგრაცია, პოლიტიკა);

PR შემოწმების ფურცლები: "რა შეიცვალა? „„, უსაფრთხოება? „„, საპირისპირო თავსებადობა? „„, მიგრაცია? ».

12) უსაფრთხო განვითარება (SSDL) და მიწოდების ჯაჭვი

SCA (დამოკიდებულების ანალიზი) და allowlist წყაროები;

SAST/DAST/IAST არტეფაქტის ტიპის მიხედვით;

SBOM თითოეული ბილეთისთვის, შენახვა არტეფაქტურ საცავებში;

სურათების ხელმოწერა, სერტიფიკაცია (SLSA დონე);

საიდუმლოების პოლიტიკა: არ არსებობს საიდუმლოებები Git- ში, როტაცია, დროებითი კრედიტები;

Policy-as-Code (OPA/Conftest) ინფრასტრუქტურული PR.

13) ფიჩეფლაგები, ექსპერიმენტები და წინასწარი გარემო

SDK ძაფები შაბლონებში, დემარკაცია: ops დროშები vs საკვები;

პროგრესული განლაგება (1%, 25% - 100%), სწრაფი პაკეტი;

თითოეული PR- ის გარემოცვის გადახედვა (უნიკალური URL, ტრეისი, ტესტის მონაცემები), ავტომატური ამოღება merge/close- ის შემდეგ.

14) ბოტები და ავტომატიზაცია

ჩეთ-ბოტები/deploy ,/rollback ,/logs ,/runbook;

მანქანის ეტიკეტები და ავტომობილების ტრეკერი;

თიკეტების შაბლონები (ინციდენტი, ცვლილება, RFC);

დამოკიდებულების ავტომატური განახლება ტრამპლინირებით და „მწვანე“ ფილიალებით.

15) დოკუმენტაცია და ტრენინგი

„ცოცხალი“ სპეკები (OpenAPI/Proto), როგორც ჭეშმარიტების წყარო;

tech notes/RFC ზოგადი შაბლონების საშუალებით, Git- ის ავტო გამოცემა;

ვიდეო დემო „როგორ ვიწყებ პროექტს 10 წუთში“;

DevPortal- ის „ქვიშის ყუთი“ ეტაპობრივი სცენარებით.

16) შესრულების მეტრიკა (DORA/SPACE)

DORA: Lead Time, Deployment Frequency, MTTR, Change Failure Rate;

SPACE: კმაყოფილება, შესრულება, აქტივობა, კომუნიკაცია;

სამიზნეები კვარტლისთვის: Lead Time 30% -ით, გამოშვების სიხშირე, ონბონინგის დრო N საათამდე.

17) წვდომის კონტროლი და მრავალ ტენანტობა

როლები საინჟინრო პროფილებისთვის (dev, reviewer, releng, platform);

საშუალო პოლიტიკოსები: ვის შეუძლია ზიანი მიაყენოს dev/stage/scream;

ინდივიდუალური კვოტები/ლიმიტები და namespace- ის იზოლაცია წინასწარი/fich ფილიალებისთვის.

18) ინსტრუმენტები მონაცემებისა და ანალიტიკისთვის

ადგილობრივი პროფილები მოვლენების წასაკითხად (Kafka/NATS) და rapley;

სინთეზური გენერატორები და დამპების ანონიმიზატორები;

Ad-hoc ლეპტოპები/სკრიპტები, რომლებიც აანალიზებენ მომსახურებისა და გამოშვებების მეტრიკის ხარისხს.

19) გზის განხორციელების რუკა

M0-M1 (MVP): DevPortal, მომსახურების შაბლონები, ძირითადი CI (lint + unit + build), ადგილობრივი შეკრება dev-containers- ის საშუალებით, ლოგიკა/მეტრიკა.
M2-M3: კონტრაქტის ტესტები, გარემოცვა, ინტეგრაციის ტესტები ტესტებით, SAST/SCA, SBOM.
M4-M6: ფიჩეფლაგები, პროგრესული მონაცვლეობა, Dashboards as Code, პოლიცია-as-code, დისტანციური dev-puls, SDK ავტოგენი.
M6 +: ორკესტრის გამოშვება, „ერთი ღილაკის“ გამოცდილება, კომპონენტების/ბიბლიოთეკების შიდა ფანჯარა, DORA/SPACE მეტრიკა DevPortal- ზე.

20) პლატფორმის სიმწიფის სია (ჩამკეტი)

• სერვისის შექმნა „ერთი დაწკაპუნებით“ იძლევა სამუშაო ჩარჩოს მეტრიკებით/ლოგოებით/ტრეისებით.
• წინასწარი გარემო ავტომატურად იზრდება თითოეული PR- სთვის.
• ხელშეკრულების ტესტები სავალდებულოა და ბლოკავს შეუთავსებელ ცვლილებებს.
• SBOM ქვეყნდება თითოეული ბილეთისთვის, გაფორმებულია სურათები.
• დაკვირვება/ალერტები და დაშბორდები - კოდი საცავებში.
• Ficheflages ხელმისაწვდომია კონსოლიდან, stingles არის პროგრესული.
• Runbooks/playbooks უკავშირდება ალერტებს და ჩანს DevPortal- ში.
• DORA/SPACE მეტრიკები ნაჩვენებია DevPortal- ის მთავარ გვერდზე.
• ახალი დეველოპერის Onboarding - 1 სამუშაო დღე პირველ PR- მდე.

მოკლე დასკვნა

დეველოპერის ძლიერი შიდა პლატფორმა ჰეტეროგენულ ნაკადს გადააქცევს მიწოდების ერთ „კონვეიერად“: „შექმენით სერვისი“ - დან „prods უსაფრთხო მონაცვლეობით“. სტანდარტიზებული შაბლონები, DevPortal, ტესტირების ხელშეკრულება, გარემოცვა, დაკვირვება და ნაგულისხმევი უსაფრთხოება იძლევა სწრაფ, პროგნოზირებად გამოშვებებს კომპრომისის გარეშე ხარისხისა და შესაბამისობის შესახებ.