Zbërthim i Punës i Gjurmueshëm
Çdo detyrë implementimi lidhet me një kërkesë specifike ose një kriter pranimi — jo me një përshkrim të përgjithshëm dhe të dobët të një veçorie.
Zhvillim & Integrim · Hapi 04 · Si Punojmë
Një Specifikim Bëhet Softuer.
Dizajni i Zgjidhjes prodhon një specifikim të testuar dhe kritere të përcaktuara të pranimit. Kjo fazë kthen atë specifikim në softuer të funksionueshëm dhe të verifikuar — i integruar me sistemet me të cilat duhet të funkcioni në, dhe i provuar kundër kritereve të përcaktuara para fillimit të zhvillimit.
Zhvillimi këtu nuk është interpretim. Çdo vendim implementimi gjurmohet prapa deri tek një specifikim i prodhuar gjatë dizajnit — jo te ajo që një zhvillues supozoi se ndoshta ishte qëllimi.
Jo kjo pyetje
"A funksionon kodi?"
Kjo pyetje, në vend të kësaj
"A i përmbush sistemi i ndërtuar kriteret e pranimit të përcaktuara para se të fillonim — nën kushte reale integrimi, jo vetëm në izolim?"
Implementim · Verifikim · Integrim · Gjurmueshmëri · Disiplina e Dorëzimit
Pse Zhvillimi Ndjek Dizajnin
Këtu nuk bëhen supozime.
Çdo input për këtë fazë është prodhuar gjatë Dizajnit të Zgjidhjes: Dokumenti i Specifikimit të Zgjidhjes, Raporti i Vlerësimit të Prototipit, dhe Kriteret e Pranimit & Plani i Testimit. Zhvillimi sipas një specifikimi të patestuar thjesht do të zhvendoste përsëri në kodin e prodhimit rrezikun që prototipimi synonte të eliminojë.
Specifikimi i Zgjidhjes + Kriteret e Pranimit → Implementim i Verifikuar
Pse Disiplina e Dorëzimit Ka Rëndësi
Shpejtësia dhe qëndrueshmëria matin së bashku — nuk duhet të sakrifikohen.
Performanca e dorëzimit të softuerit nuk është thjesht çështje e sa shpejt një ekip shkruan kod. Kërkimet nga Forsgren, Humble dhe Kim — botuar në Accelerate: The Science of Lean Software and DevOps (2018), bazuar në kërkimin multi-vjeçar të programit DevOps Research and Assessment (DORA) në mijëra organizata — identifikuan dy kategori të performancës inxhinierike që duhet të maten së bashku: throughput (përpunimi) dhe qëndrueshmëria.
Koha e Kalimit
Sa kohë kërkon që një ndryshim i verifikuar të kalojë nga commit në një gjendje të gatshme për vendosje (deploy).
Forsgren, Humble & Kim, Accelerate (2018); DORA, kërkimet State of DevOps.
Shkalla e Dështimeve të Ndryshimeve
Përqindja e ndryshimeve që sjellin një defekt që kërkon riparim.
Forsgren, Humble & Kim, Accelerate (2018); DORA, kërkimet State of DevOps.
Një ekip që dorëzon shpejt por shpesh prish gjëra nuk performon mirë sipas këtij studimi — ashtu siç nuk performon mirë as një ekip që dorëzon në mënyrë të sigurt por shumë ngadalë për të qenë i rëndësishëm. OpenQCore mban të dy dimensionet në konsideratë gjatë kësaj faze, në vend që të optimizojë vetëm për shpejtësinë.
Nga Specifikimi tek Implementimi
Çdo pjesë pune gjurmohet deri te një kërkesë.
Puna e implementimit zbërthehet drejtpërdrejt nga Specifikimi i Zgjidhjes dhe Kriteret e Pranimit — jo nga një kuptim i përgjithshëm i asaj që dizajni "po synonte."
Përkufizimi i Përfundimit
Një detyrë nuk konsiderohet e përfunduar vetëm sepse është shkruar kodi. Ajo është e përfunduar kur, nën testim, plotëson kriterin e pranimit me të cilin është e lidhur.
Kontrolli i Diftimit të Specifikimit
Kur implementimi zbulon një boshllëk ose paqartësi në specifikim, specifikimi përditësohet dhe rishikohet — jo që të interpretohet në heshtje nga personi që po shkruan kodin atë ditë.
Verifikim i Drejtuar nga Testet
Verifikimi ndodh në çdo nivel, jo vetëm në fund.
OpenQCore strukturon verifikimin sipas piramidës së testimit — një kornizë e përdorur gjerësisht, e popullarizuar nga Mike Cohn, për të balancuar mbulimin e testeve nëpër nivelet e një sistemi në vend që ta përqendrojë atë në testet e ngadalta dhe të shtrenjta end-to-end.
Testet Unitare
Verifikim i shpejtë dhe i izoluar i komponentëve individualë kundrejt sjelljes së tyre të specifikuar — përfshirë reagimin ndaj të dhënave të pavlefshme.
Testet e Integrimit
Verifikimi që komponentët ndërveprojnë si duhet sipas kontratave të të dhënave të përcaktuara gjatë projektimit të zgjidhjes.
Testet end-to-end
Verifikimi i rrjedhave të punës të plota kundrejt kritereve të pranimit të përcaktuara përpara se të fillonte zhvillimi — shtresa më e vogël dhe më e kushtueshme, e rezervuar për atë që me të vërtetë e kërkon.
Qëllimi nuk është numri maksimal i testeve. Është besimi që kriteret e pranimit janë vërtet të përmbushura, në shtresën me koston më të ulët që është në gjendje ta provojë këtë.
Testimi i Integrimit dhe i Kontratave
Një kontratë API është e vërtetë vetëm nëse testohet, jo vetëm nëse dokumentohet.
Kontratat e të dhënave dhe API-të të përcaktuara gjatë Projektimit të Zgjidhjes nuk trajtohen si dokumentacion që ndiqet në mënyrë joformale. OpenQCore aplikon testimin e kontratave të drejtuara nga konsumatorët — një qasje e formalizuar në mjete si Pact — ku çdo pikë integrimi verifikohet kundrejt një kontrate të ekzekutueshme që të dyja palët e integrimit duhet të përmbushin.
Kjo është veçanërisht e rëndësishme për sistemet që duhet të lidhen me infrastrukturën ekzistuese: një kontratë që kontrollohet vetëm me rishikim manual mund të zhvendoset në heshtje ndërsa secila palë bën ndryshime. Një kontratë që testohet automatikisht nuk mundet.
Rishikim i Kodit & Verifikim Statik
Një rishikues i dytë kap atë që autori nuk e sheh.
Kërkime të cituara gjerësisht mbi rishikimin e kodit nga kolegët — përfshirë studimin e kryer në Cisco Systems dhe të popullarizuar në Cohen et al.'s Best Kept Secrets of Peer Code Review — gjetën se efektiviteti i rishikimit varet shumë nga ritmi dhe shtrirja: rishikime më të vogla, më të shpeshta dhe të kryera pa presion kohe kapin shumë më tepër defekte sesa rishikimet e mëdha të kryera shpejt.
OpenQCore aplikon rishikim të strukturuar të kodit së bashku me analizën statike të automatizuar — stil, kompleksitet dhe skanim për dobësi të njohura — si një shtresë verifikimi të përhershme, jo si një kalim mirësjelljeje opsionale para bashkimit.
Pipeline i Integrimit të Vazhdueshëm
Çdo ndryshim verifikohet në të njëjtën mënyrë, automatikisht.
Commit → Ndërtim i Automatizuar → Teste Unitare & të Integrimit → Analizë Statike & e Sigurisë → Verifikim i Kontratave → Gati për Vendosje.
Verifikimi manual dhe i papërputhshëm nuk rritet me shkallë, dhe nuk jep një sinjal të besueshëm nëse një ndryshim është vërtet i sigurt për t'u lëshuar — një vendim që merret në fazën tjetër, Vendosje & Aktivizim. Ajo që garanton kjo fazë është që një ndryshim që arrin atë portë është tashmë verifikuar kundrejt të njëjtit standard automatik si çdo ndryshim më parë.
Praktika të zhvillimit të sigurt
Siguria verifikohet gjatë zhvillimit, jo e audituar më pas.
Praktikat e zhvillimit të OpenQCore përputhen me strukturën e përshkruar në Kornizën për Zhvillimin e Sigurt të Softuerit të NIST (SP 800-218) — duke organizuar aktivitetet e sigurisë rreth përgatitjes së organizatës, mbrojtjes së softuerit, prodhimit të softuerit të mirë të siguruar, dhe përgjigjes ndaj dobësive.
Skanim i Varësive dhe Dobësive
Skanim i automatizuar i varësive të palëve të treta për dobësi të njohura si pjesë e pipeline-it standard, jo një auditim manual periodik.
Modelimi i Kërcënimeve
Vlerësim i strukturuar se si një komponent mund të keqpërdoret, i informuar nga mënyrat e dështimit të përcaktuara gjatë dizajnit të zgjidhjes.
Zbatimi i Parimit të Privilegjit Minimal
Akseset dhe lejet zbatohen në nivelin më të ngushtë që përmbush specifikimin — jo në nivelin më të gjerë që është i përshtatshëm.
Porta e Verifikimit të Integrimit
Një ndërtim nuk është i gatshëm vetëm sepse kompilon.
Çdo ndryshim arrin një portë verifikimi të përcaktuar para se të konsiderohet për vendosje.
Gati për vendosje
Të gjitha kriteret e pranimit janë përmbushur, të verifikuara përmes testeve të automatizuara, kontrolleve të kontratave dhe skanimit të sigurisë.
Kthim për Riparime
Defekte specifike dhe të identifikuara duhet të zgjidhen para se ky ndryshim të vazhdojë.
Kthim te Dizajni
Zbatimi zbuloi se vetë specifikimi nuk qëndron në kushtet reale — përgjigjja e duhur është rishikimi i specifikimit, jo kodimi për ta anashkaluar atë.
Eskalimi i Rrezikut
U identifikua një rrezik i sigurisë, përputhshmërisë ose arkitekturës që kërkon një vendim mbi autoritetin e ekipit të zhvillimit.
Një pipeline që gjithmonë arrin "gati për vendosje" nuk po verifikon asgjë.
Çfarë prodhon kjo fazë
Softuer i gatshëm për vendimin për ta vendosur — ende i pa vendosur.
Në varësi të fushës së angazhimit, kjo fazë prodhon:
Bazë kodi e verifikuar
Zbatim i gjurmueshëm në specifikim, që kalon të gjitha shtresat e verifikimit të përcaktuara.
Raporti i mbulesës së testeve
Rezultatet e testeve unitare, të integrimit dhe end-to-end të përputhura me kriteret e pranimit.
Suita e testeve të kontratës
Verifikim ekzekutues i çdo pike integrimi të përcaktuar gjatë dizajnit të zgjidhjes.
Regjistrimet e Rishikimeve të Kodit
Historia e rishikimeve të dokumentuar dhe zgjidhja e çështjeve të ngritura.
Rezultatet e skanimeve të sigurisë
Gjetjet për varësitë, dobësitë dhe analizën statike, dhe zgjidhjet përkatëse.
Dokumentacioni i Pipeline-it CI
Rrjedha e verifikimit e automatizuar e aplikuar për këtë ndryshim, dhe për çdo ndryshim pas tij.
Nga Zhvillimi te Vendosja & Aktivizimi
Softueri i verifikuar nuk është ende softuer në prodhim.
Zhvillimi & Integrimi prodhon softuer që është verifikuar në përputhje me specifikimet e tij — jo softuer që është shpërndarë, monitoruar, ose vërtetuar si i qëndrueshëm nën ngarkesë reale prodhimi. Faza e ardhshme rregullon se si, kur dhe me çfarë sigurie ai softuer arrin në prodhim.
Specifikimi i Zgjidhjes → Zbatimi i Verifikuar → Vendosja & Aktivizimi
Hapi 05
Vendosja & Aktivizimi
Lëshoni softuerin e verifikuar në prodhim në mënyrë të sigurt, të qëllimshme dhe me një rrugë të përcaktuar për kthim pas.
Referencat Kërkimore & Metodologjike
Forsgren, N., Humble, J., & Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud, DORA State of DevOps research
Burimi i metrikeve të performancës së dorëzimit të përmendura më sipër.
Cohn, M. — Succeeding with Agile (2009)
Burimi i konceptit të piramidës së testimit të përmendur në verifikimin e drejtuar nga testet më sipër.
Cohen, J. et al. — Best Kept Secrets of Peer Code Review (SmartBear, based on research at Cisco Systems)
Burimi i gjetjeve mbi efektshmërinë e rishikimit të kodit të referuara më sipër.
Pact / Consumer-Driven Contracts
Një qasje e konsoliduar për kontrata integrimi të ekzekutueshme, të verifikuara automatikisht, e përmendur në seksionin e testimit të integrimit më sipër.
NIST — Secure Software Development Framework, SP 800-218
Burimi i strukturës së referuar në praktikat e zhvillimit të sigurt më sipër.