GitOps suurarvutitele: moodsa versioonikontrolli toomine z/OS-i

IN-COM September 16, 2026 Rakendused, Koodi ülevaade, Arendajad, Mõju analüüs

Uus arendaja liitub suurarvutite meeskonnaga. Ta on viis aastat kirjutanud Java mikroteenuseid Giti, GitHubi, pull requestide, koodiülevaadete ja CI/CD torujuhtmete abil. Ta teab, kuidas luua funktsiooniharu, esitada PR-i, jälgida automatiseeritud testide käivitamist, saada tagasisidet kolleegidelt ja ühendada, kui kontrollid on edukad. Esimesel päeval suurarvutite meeskonnas õpib ta töövoogu: avage ISPF, navigeerige lähtekoodi PDS-i, muutke liiget otse, salvestage see, esitage kompileeritud JCL, kontrollige SYSOUT-i vigade suhtes. Haru puudub. Puudub ajalugu peale selle, mida näitavad järjekorranumbrid veergudes 1-6. Puudub pull request. Puudub automatiseeritud testimisvärav. Kui tema ja tema kolleeg mõlemad redigeerivad sama liiget samaaegselt, kirjutab teine salvestus esimese üle ilma ühendamise, hoiatuse või konfliktita, vaid vaikse andmekaota.

See on töövoog, mille GitOps for mainframe on loodud asendama. Mitte z/OS platvorm, mitte COBOL keel, mitte tõestatud tehingute töötlemine, mida suurarvuti pakub viie üheksa minutilise kättesaadavusega, vaid lihtsalt lähtekoodi haldamise töövoog, mis eelneb hajutatud versioonikontrollile ja pole tarkvarameeskondade tööga sammu pidanud. Äriline põhjus on üha konkreetsem: suurarvutite meeskonnad, kes võtavad kasutusele Git-põhised töövood, teatavad uute arendajate kiiremast sisseelamisest (sealhulgas kasvavast kohordist, kellel on ainult kaasaegsete tööriistade kogemus), paremast nähtavusest muudatuste ajaloos vastavuse ja auditi jaoks, paremast koostööst suurarvutite ja hajutatud arendusmeeskondade vahel ning väiksemast riskist, mis tuleneb kahekordse redigeerimise ülekirjutamise probleemist, mis on ISPF-i teekide haldamisel alati olnud.

Ainult mõjutatud programmide loomine

SMART TS XL identifitseerib iga programmi, mis sisaldab muudetud koopiaraamatut enne, kui CI-torujuhe otsustab, mida kompileerida.

SAAGE LISATEAVET…

Sisukord

Mida GitOps suurarvutite jaoks tegelikult tähendab

GitOps on operatsioonimudel, kus Git on nii rakenduskoodi kui ka infrastruktuuri konfiguratsiooni ainus tõene allikas. Iga süsteemi, koodi, konfiguratsiooni ja juurutamise definitsiooni muudatus tehakse Giti commit'i kaudu. Giti repositoorium on autoriteetne kirje; töötav süsteem viiakse vastavusse Giti andmetega.

Suurarvutite puhul tähendab see konkreetset kohustuste kogumit:

Git on COBOL-i lähtekoodi autoriteetne allikas. z/OS-i PDS-teek on juurutamise artefakt, mis kompileeritakse ja töötab tootmiskeskkonnas, mitte tõene allikas. Tõeline allikas on Giti repositoorium. Kui PDS ja Giti repositoorium on eriarvamusel, on Gitil õigus.

Iga muudatus läbib pull-requesti. Otseseid PDS-i muudatusi ei tehta. Giti töövoo väliselt ei toimu hädaolukorras kompileerimist ja reklaamimist. Koheselt vajalik muudatus läbib kiirendatud PR-i, millel on potentsiaalselt väiksemad ülevaatusnõuded tõelise hädaolukorra korral, kuid see läbib Giti.

Automatiseeritud torujuhtmed tegelevad ehituse ja edutamisega. Arendaja ühendab oma PR-id; torujuhe kompileerib mõjutatud programmid, käivitab automatiseeritud testid ja edutab kompileeritud laadimismoodulid sobivasse teeki. Arendaja ei esita kompileeritud JCL-i käsitsi.

Giti muudatuste ajalugu on auditeerimisjälg. Iga tootmiskeskkonnas tehtud muudatus on jälgitav kindla muudatuste, autorite, PR-ide ja pull request'i töövoo järgimise korral ka kindlate arvustajate ja testitulemuste komplektini.

See on oluline töövoo muutus meeskondadele, kes on harjunud ISPF-põhise arendusega. Üha enam on see ka töövoog, mida organisatsioonid vajavad talentide lõhe ületamiseks: uued arendajad, kes tunnevad Giti ja mitte midagi muud, saavad COBOL-i arenduses osaleda ilma ISPF-i teekide halduskonventsioone õppimata.

Tehnilised väljakutsed: mida ükski teine artikkel ei selgita

COBOL-i lähtekoodi Giti teisaldamine ei ole nii lihtne kui repositooriumi loomine ja failide kopeerimine sinna. Migratsiooni raskendavad neli z/OS-i tehnilist väljakutset:

1. EBCDIC vs. UTF-8 kodeering

z/OS salvestab tähemärke EBCDIC-vormingus (laiendatud binaarkoodiga kümnendkoodivahetuskood), Git aga salvestab faile UTF-8-vormingus. Iga fail, mis liigub suurarvuti ja Giti hoidla vahel, tuleb transkodeerida. Kui transkodeerimist ei tehta õigesti, kui eeldatakse valet koodilehte, kui teisendamine toimub ebajärjekindlalt või kui failid edastatakse ilma teisendamiseta, siis COBOL-allikas rikutakse märkamatult.

z/OS Unix System Services (USS) on sild: PDS-i COBOL-lähtekood transkodeeritakse UTF-8-ks, kui see kirjutatakse USS-failisüsteemi, kus Git saab sellega töötada. Kui Giti hoidla kloonitakse USS-i, märgistatakse failid nende kodeeringuga, et z/OS-i tööriistad teaksid, kuidas neid tõlgendada.

sisse lööma

# z/OS USS: correctly tag a Git-managed COBOL source file
chtag -t -c IBM-1047 CUSTPROC.cbl

# Verify the tag
ls -T CUSTPROC.cbl
# Output: t IBM-1047   T=on  CUSTPROC.cbl

# The Git checkout hook should apply this automatically
# so developers don't have to tag files manually

2. Fikseeritud vorminguga allika ja veeru semantika

COBOL-lähtekoodifailid kasutavad fikseeritud vorminguga struktuuri veeruspetsiifilise semantikaga:

Columns 1-6:   Sequence numbers (optional; ISPF editors fill these automatically)
Column 7:      Indicator (* = comment, - = continuation, D = debug line)
Columns 8-11:  Area A (division/section/paragraph names, level numbers 01/77)
Columns 12-72: Area B (executable statements, clauses)
Columns 73-80: Identification (program name, historically used for card identification)

COBOL-i lähtekoodi Giti erinevus, mis näitab muudatusi veergudes 73–80, näitab tavaliselt järjekorranumbri või identifitseerimisvälja muudatusi, mitte koodi funktsionaalseid muudatusi. Erinevate failide tööriist, mis neid veergude semantikaid ei mõista, tekitab müra, mis varjab tegelikke muudatusi. COBOL-i repositooriumi Giti konfiguratsioon peaks sisaldama järgmist: .gitattributes mis seob COBOL-failid erinevusdraiveriga, mis eemaldab identifitseerimisvälja või ignoreerib seda:

ini

# .gitattributes: configure COBOL-aware diff
*.cbl  diff=cobol
*.cob  diff=cobol
*.cpy  diff=cobol

# .gitconfig (or repo-level config): define the cobol diff driver
[diff "cobol"]
    xfuncname = "^[0-9A-Z][0-9A-Z -]+"
    wordRegex = "[A-Z][A-Z0-9-]+"

3. PDS-i liikmenime piirangud

PDS-i liikmete nimed võivad olla piiratud 8 tähemärgiga (suurtähed, tähed, numbrid ja ...). $, #, @Gitis on failinimi PDS-i liikme nimi (ilma laiendita või standardse laiendiga). .cbl laiendus lisatud kokkuleppeliselt). 8 tähemärgi piirang loob nimepiirangu: CUSTUPDT vastab selgelt PDS-i liikmele; customer-account-update-processor ei ole.

Praktikas toimiv kokkulepe: jätke liikmete nimed baasfailinimeks (8 tähemärki), lisage .cbl laiendust Gitis allika tuvastamiseks ja kasutage Giti kataloogistruktuuri, et pakkuda nimeruumi, mida PDS-i nimetamine ei võimalda:

repository/
├── CUSTMGMT/          # Logical application group (no PDS equivalent)
│   ├── CUSTUPDT.cbl   # Maps to PDS member CUSTUPDT
│   ├── CUSTINQ.cbl
│   └── CUSTSRCH.cbl
├── COPYBOOKS/
│   ├── CUSTMSTR.cpy   # Maps to PDS member CUSTMSTR
│   └── TRANREC.cpy
└── JCL/
    ├── CUSTNITE.jcl
    └── CUSTMON.jcl

4. Autoriteetse allika probleem

PDS-põhiselt Git-põhisele arendusele üleminekul sisaldavad nii PDS kui ka Git lähtekoodi koopiaid. Kumb on autoriteetne? Vastus peab olema üheselt mõistetav enne, kui uue töövoo kaudu tehakse tootmismuudatusi.

(cite index=”42-1″>Milline süsteem sisaldab autoriteetset allikat: Git, teekihaldur või sünkroonimisprotsessi genereeritud väljund? Kui see vastus on ebaselge, kulutavad meeskonnad aega süsteemidevaheliste erinevuste lahendamisele, mitte väärtuse pakkumisele. Git-first mudel annab selgema vastuse. Git sisaldab autoriteetset allikat ja salvestab selle ajaloo. Torujuhe kasutab seda allikat testitud ja jälgitavate artefaktide loomiseks juurutamiseks.

Üleminekujärjestus, mis selle ebaselguse lahendab: Giti repositooriumi määramine autoriteetseks allikaks kindlal kuupäeval; pärast seda kuupäeva on iga PDS-i muudatus poliitika rikkumine, mis tuleb enne tööpäeva lõppu eskaleerida ja Giti tagasiportida; hädaolukorra kiirparandustele eraldatakse kiirtee PR-töövoog, mitte PDS-i redigeerimise erand. Üleminekuperiood, mil mõlemat süsteemi hooldatakse, peaks olema nii lühike kui operatiivselt võimalik, sest iga kahe allikaga hoolduspäev on potentsiaalse lahknemise päev.

Suurarvuti GitOpsi tööriistakett

Giti z/OS-i edastustorustikuga ühendavad neli tööriistakategooriat:

Lähtekoodi haldus ja IDE: IBM Developer for z/OS (IDz) pakub traditsioonilist Eclipse'il põhinevat IDE-d ISPF-stiilis redigeerimisega ja Giti integratsiooniga. Teise võimalusena pakub VS Code koos Zowe Exploreri laiendusega moodsat IDE-d, mis ühendub z/OS-iga Zowe API raamistiku kaudu ilma IDz-d vajamata. Meeskonnad, kes soovivad meelitada ligi kaasaegsete tööriistadega tuttavaid arendajaid, eelistavad tavaliselt VS Code'i.

Zowe raamistik: Zowe on avatud lähtekoodiga raamistik, mis pakub z/OS-ile REST API-sid, avaldades andmestiku toiminguid, tööde esitamist ja USS-failidele juurdepääsu standardiseeritud HTTP-liideste kaudu, mida standardsed CI/CD-tööriistad saavad kasutada. Ilma Zowe'ta (või kommertsliku ekvivalendita) pole GitHub Actionsi käitajal või Jenkinsi agendil standardset viisi z/OS-iga suhtlemiseks.

IBM Dependency Based Build (DBB): DBB on ehitustööriist, mida IBM pakub spetsiaalselt suurarvutite GitOpsile. See mõistab COBOL-i kompileerimise sõltuvusi, milliseid koopiaraamatuid iga programm sisaldab, milliseid DBD-sid ja PSB-sid on vaja IMS-programmide jaoks, milliseid BIND-e on vaja Db2 jaoks, ning kasutab seda sõltuvuste mõistmist, et määrata, mida tuleb kompileerida, kui antud failikomplekt muutub.

Muudatuste haldamine ja juurutamine: ISPW (CA Brightside), UrbanCode Deploy ja Rocket Software ISPW pakuvad edutamishaldust, mis liigutab kompileeritud laadimismooduleid arendusteekidest testimiskeskkondade kaudu tootmiskeskkonda, koos reguleeritud keskkondade jaoks vajalike kinnitamistöövoogude ja auditeerimisradadega.

Tööriistaketi kiht	Avatud lähtekoodiga / IBM-i variant	Kommertslik alternatiiv
IDE	VS Code + Zowe Explorer	IBM IDz, Broadcom IDz
z/OS API sild	Zowe CLI + API kiht	Rocket ConnectZen, California Brightside
Ehita orkestreerimine	IBM DBB	BMC Compuware Topaz töölaud
CI/CD jooksja	Jenkins, GitHubi toimingud	Azure DevOps, GitLabi CI
Muutuste juhtimine	Zowe + DBB juurutamine	ISPW, UrbanCode'i juurutamine
Allika reklaamimine	Giti ühendamine peaharuga	ISPW reklaamimise töövoog

Torujuhe: PR-ist tootmiseni

COBOL-i muudatuse otsast lõpuni GitOpsi torujuhe hõlmab hajutatud CI/CD platvormi ja z/OS-i teostuskeskkonda:

yaml

# GitHub Actions: COBOL GitOps pipeline
name: Mainframe COBOL Pipeline

on:
  pull_request:
    paths:
      - '**/*.cbl'
      - '**/*.cpy'
      - '**/*.jcl'

jobs:
  impact-analysis:
    runs-on: ubuntu-latest
    outputs:
      affected: ${{ steps.analyze.outputs.affected_programs }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Identify changed files
        id: changes
        run: |
          CHANGED=$(git diff --name-only origin/main...HEAD \
                    | grep -E '\.(cbl|cpy|jcl)$')
          echo "changed=$CHANGED" >> $GITHUB_OUTPUT

      - name: Analyze dependency scope
        id: analyze
        # SMART TS XL or DBB dependency analysis determines
        # which programs are affected by the changed files
        run: |
          echo "Resolving dependency scope for: ${{ steps.changes.outputs.changed }}"
          # Output: the specific programs that must be compiled/tested

  compile-and-test:
    needs: impact-analysis
    runs-on: [self-hosted, zos-runner]  # Runner with z/OS connectivity
    steps:
      - uses: actions/checkout@v4

      - name: Compile affected COBOL programs (via Zowe + DBB)
        run: |
          zowe dbb build \
            --sourceDir ./CUSTMGMT \
            --affected "${{ needs.impact-analysis.outputs.affected }}" \
            --workDir /u/devops/builds/${{ github.run_id }}

      - name: Run unit tests
        run: |
          zowe zunit run \
            --programs "${{ needs.impact-analysis.outputs.affected }}" \
            --results-dir /u/devops/results/${{ github.run_id }}

      - name: Static compliance check (before promotion)
        run: |
          # Hardcoded credential check, FILE STATUS validation,
          # naming convention compliance
          zowe smart-ts-xl analyze \
            --scope "${{ needs.impact-analysis.outputs.affected }}"

  promote-to-test:
    needs: compile-and-test
    if: github.event_name == 'pull_request' && github.base_ref == 'main'
    runs-on: [self-hosted, zos-runner]
    steps:
      - name: Promote to TEST library (via ISPW)
        run: |
          zowe ispw promote \
            --programs "${{ needs.compile-and-test.outputs.compiled }}" \
            --from DEV --to TEST \
            --change-request ${{ github.event.pull_request.number }}

Selle protsessi kriitiliseks elemendiks on mõjuanalüüsi etapp: selle kindlaksmääramine, millised COBOL-programmid tuleb kompileerida ja testida, kui PR muudab konkreetset lähtekoodifailide komplekti. Ilma selle etapita kompileerib protsess kas kõik (aeglane ja kulukas) või ainult otseselt muudetud failid (puuduvad programmid, mis sõltuvad muudetud koopiaraamatutest).

Sõltuvuslünk: miks mõjuanalüüs on kõige raskem osa

Git teab täpselt, millised failid pull-requestis muutusid. Git ei tea, milliseid teisi programme need muudatused mõjutavad.

PR, mis muudab CUSTMSTR.cpy, kliendi põhikirje paigutust määrav märkmik, ei muuda failide arvu osas midagi: ühte faili muudeti. Aga CUSTMSTR.cpy on kaasatud 47 COBOL-programmi. Kõik 47 tuleb uuesti kompileerida. Kui kompileeritakse ainult selgesõnaliselt muudetud fail, jäävad 46 programmid tootmisse koopiaraamatu definitsiooniga, mis enam ei vasta nende kompileeritud binaarfailile. Mittevastavus on vaikne, kuni programm käivitub ja proovib lugeda kirjet, kasutades vana paigutust, võrreldes uue paigutusega kirjutatud andmetega.

See on suurarvutite GitOpsi sõltuvuslünk: ehitussüsteem peab teadma sõltuvusgraafikut, et määrata õige kompileerimise ulatus. IBM DBB lahendab selle äsja loodud repositooriumide puhul, luues oma ehitusprotsessi osana selgesõnalise sõltuvuskaardi. Pärandkeskkondade puhul, kus tuhanded programmid on loodud enne DBB-d, tuleb esialgne sõltuvuskaart luua olemasoleva allika staatilise analüüsi põhjal.

Neli sõltuvustüüpi, mis on COBOL-i ehituse ulatuse määramisel olulised:

COPY laused , kõige sagedasem sõltuvus. COPY kaudu lisatud kopeeritud raamatu muutmine nõuab iga seda sisaldava programmi uuesti kompileerimist.

CALL-laused , staatilised alamprogrammide väljakutsed. Kui kutsutava programmi liides muutub (parameetrid, tagastuskoodid), võib olla vaja kutsujaid uuendada ja uuesti kompileerida.

SQL INCLUDE , manustatud SQL-programmid, mis sisaldavad DCLGEN-i liikmeid (Db2 tabelite andmeklassi generaatorid). Db2 skeemi muudatus, mis genereerib uue DCLGEN-i, nõuab iga seda sisaldava programmi uuesti kompileerimist.

JCL DD andmestike viited , JCL-i muudatused, mis viitavad erinevatele andmestike või kasutavad erinevaid programminimesid, mõjutavad operatiivset torujuhet, mitte ainult programmi kompileerimist.

Vana töövoog vs Giti töövoog

Aspekt	ISPF PDS-põhine töövoog	Giti-põhine GitOpsi töövoog
Tõe allikas	PDS-teek z/OS-is	Giti hoidla
Redigeerimismehhanism	ISPF-i toimetaja, otse PDS-i liikmetele redigeerimine	VS Code / IDz Giti integratsiooniga
Muudatuste jälgimine	Järjekorranumbrid veergudes 1–6	Giti commit'i ajalugu koos autori, ajatempli ja sõnumiga
Samaaegne redigeerimine	Teine salvestus kirjutab esimese üle (vaikne kaotus)	Harupõhine arendus; ühinemiskonfliktide tuvastamine
Koodi ülevaade	Mitteametlik, laua taha kõndimise võimalus	Struktureeritud ülevaatuse ja kinnitusega pull-päring
Ehituspäästik	JCL-i käsitsi esitamine	Automatiseeritud PR-i või ühinemise torujuhtme kaudu
Mõjutatud ulatuse arvutamine	Manuaalsed teadmised; taasta kõik vaikeseadeteks	Sõltuvusanalüüs määrab mõjutatud programmid
Kontrolljälg	Manuaalsete muudatuste logi; puudulik	Giti logi + PR-metaandmed; täielik ja päringutele allutatav
Uute arendajate sisseelamine	ISPF-i koolitus on vajalik	Git-standardile vastav sissejuhatus; moodne IDE
Hädaolukorra muudatused	Otsene PDS-i redigeerimine; sageli jälgimata	Kiirendatud PR-töövoog; täielikult jälgitav

Alumises reas koondub ISPF-i töövoo operatsioonirisk: otse tootmise tootesisudesse tehtud hädaolukorra muudatused, mis mööduvad muudatuste haldamise protsessist, on kõige sagedasem jälgimata tootmismuudatuste allikas ja kõige sagedasem auditijälg suurarvutite muudatuste juhtimise ülevaadetes.

Kuidas SMART TS XL Võimaldab täpset suurarvuti GitOpsi

Suurarvuti GitOpsi sõltuvuslünka, lünka „Git teab, mis muutus” ja „torujuhe teab, mida kompileerida” vahel, käsitletakse sõltuvusgraafiku genereeriva COBOL-allika staatilise analüüsi abil.

SMART TS XL'S rakenduse sõltuvuste kaardistamine loob täieliku COPY sõltuvusgraafiku: iga koopiaraamatu, iga seda sisaldava programmi, iga pesastatud COPY seose ja iga CALL sõltuvuse kogu portfellis. Kui PR muudab CUSTMSTR.cpy, loob sõltuvuskaart kohe 47 seda sisaldava programmi loendi, andes CI-torustikule vajaliku ehitusulatuse sisendi õige programmide komplekti kompileerimiseks, mitte midagi enamat ega vähemat.

See sõltuvuskaart muudab ka Git-põhisele arendusele ülemineku turvaliseks: enne Giti repositooriumi määramist autoriteetseks allikaks peab olema teada täielik sõltuvusgraafik, et repositooriumi algne struktuur kajastaks programmide ja õpikute vahelisi tegelikke sõltuvussuhteid. Repositooriumi struktuur, mis eraldab õpikud neid sisaldavatest programmidest ilma dokumenteeritud sõltuvussuheteta, loob repositooriumi, mis ehitatakse õigesti ainult siis, kui juhtumisi teatakse, mis millest sõltub, mis aga kaotab versioonikontrolli eesmärgi.

Staatilise koodi analüüsi võimalus pakub eelinstallitud värava loogikat: kontrollib muudetud programme kõvakodeeritud mandaatide, puuduvate FILE STATUS deklaratsioonide, nimetamiskonventsiooni vastavuse ja muude staatiliste kvaliteedikontrollide osas, mis Giti töövoogudes toimivad PR väravatena, mitte juurutamisjärgsete leidudena.

Mõjuanalüüsi võimekus vastab PR-i ülevaatuse küsimusele: „Milline on selle muudatuse täielik ulatus?“ PR-il , mis muudab eksemplari, on mõju ulatus, mis laieneb igale programmile, mis seda sisaldab, ja igale JCL-tööle, mis neid programme käitab. Selle ulatuse nähtavaks tegemine PR-i ülevaatuse kontekstis enne muudatuse ühendamist võimaldab teha teadlikke ülevaatusotsuseid, määrata sobiva testi ulatuse ja määrata muudatuste nõuandekogule sobivad kinnitustasemed.

. ettevõtte otsing funktsioon toetab auditeerimisjälje nõuet: leida iga muudatus konkreetses programmis teatud kuupäevavahemikus (päringutav Giti logist), iga programm, mis sisaldab konkreetset koopiaraamatut (päringutav sõltuvuskaardilt), iga programm, mille on muutnud konkreetne autor (päringutav Gitist). Giti muudatuste ajaloo ja SMART TS XLstruktuurianalüüs loob täieliku ja päringuid võimaldava auditeerimisjälje, mida vastavusmeeskonnad ja muudatuste nõuandekogud vajavad.

Repositoorium peaks teadma seda, mida kood teab

Arendaja, kes liitub suurarvutite meeskonnaga viieaastase Giti kogemusega, ei palu suurarvutil muutuda pilvepõhiseks platvormiks. Ta palub, et see toetaks töövooge, mida iga tänapäevane arendusmeeskond kasutab – versioonikontrolli, koodi ülevaatust, automatiseeritud testimist ja jälgitavust. Need töövood eksisteerivad põhjustel, mis kehtivad võrdselt nii COBOLi kui ka Java kohta: topeltredigeerimise ülekirjutamise vältimine, iga tootmismuudatuse auditeeritava ajaloo loomine, koodi ülevaatuse võimaldamine enne juurutamist ja mehaanilise töö automatiseerimine, et arendajad saaksid keskenduda sisulisele tööle.

Tehnilised väljakutsed on reaalsed – EBCDIC kodeering, fikseeritud vorminguga lähtekoodi konventsioonid, PDS-i nimetamise piirangud ja autoriteetse lähtekoodi küsimus. Ükski neist pole lahendamatu. Tööriistakett, Zowe, DBB, VS Code koos Zowe Exploreriga ja muudatuste haldamise platvormid lahendavad enamiku neist. Ülejäänud lünk on sõltuvuste analüüs, mis paneb torujuhtme ehitama õige ulatuse, kui jagatud komponent muutub.

Gitis lähtekoodi haldav, CI/CD konveieri kaudu ehitatav ja automatiseeritud edastusprotsessi kaudu juurutatav suurarvuti ei ole erinev suurarvuti. See on sama suurarvuti, mis käitab samu tõestatud COBOL-programme, sama viie-üheksa-aastase töökindlusega ning on nüüd suurarvuti, millega saab liituda ja esimese nädala lõpuks produktiivne olla arendaja.