Integrimi i vazhdueshëm (CI) është praktika e integrimit të ndryshimeve të shpeshta të kodit burimor dhe sigurimit që baza e kodit të integruar të jetë në një gjendje të funksionueshme. Zakonisht, zhvilluesit bashkojnë ndryshimet në një degë integrimi dhe një sistem i automatizuar ndërton dhe teston sistemin e softuerit.
Shpesh, procesi i automatizuar funksionon në çdo kryerje ose funksionon sipas një orari, si p.sh. një herë në ditë. Grady Booch propozoi për herë të parë termin CI në vitin 1991, megjithëse ai nuk mbështeste integrimin disa herë në ditë, por më vonë, CI filloi ta përfshinte atë aspekt.
Histori
Puna më e hershme e njohur (1989) mbi integrimin e vazhdueshëm ishte mjedisi Infuse i zhvilluar nga GE Kaiser, DE Perry dhe WM Schell.
Në vitin 1994, Grady Booch përdori frazën integrim i vazhdueshëm në Analizën dhe Dizajnin e Orientuar drejt Objekteve me Aplikime (botimi i 2-të) për të shpjeguar se si, kur zhvillohet duke përdorur mikroprocese, "lëshimet e brendshme përfaqësojnë një lloj integrimi të vazhdueshëm të sistemit dhe ekzistojnë për të detyruar mbylljen e mikroprocesit".
Në vitin 1997, Kent Beck dhe Ron Jeffries shpikën programimin ekstrem (XP) ndërsa ishin në projektin e Sistemit Gjithëpërfshirës të Kompensimit Chrysler, duke përfshirë integrimin e vazhdueshëm. Beck publikoi rreth integrimit të vazhdueshëm në vitin 1998, duke theksuar rëndësinë e komunikimit ballë për ballë mbi mbështetjen teknologjike. Në vitin 1999, Beck dha më shumë detaje në librin e tij të parë të plotë mbi Programimin Ekstrem. CruiseControl, një nga mjetet e para të CI me burim të hapur, u publikua në vitin 2001.
Në vitin 2010, Timothy Fitz publikoi një artikull që detajonte se si ekipi i inxhinierisë së IMVU-së kishte ndërtuar dhe përdorur sistemin e parë praktik të CD-ve. Ndërsa postimi i tij fillimisht u prit me skepticizëm, ai shpejt u përhap dhe u përhap gjerësisht si pjesë e metodologjisë së zhvillimit të softuerëve të dobët, gjithashtu bazuar në IMVU.
Praktikat
Aktivitetet kryesore të CI janë që zhvilluesit të bashkë-lokalizojnë ndryshimet e kodit në një zonë të përbashkët integrimi shpesh dhe që baza e kodit të integruar që rezulton të verifikohet për saktësi. Pjesa e parë përgjithësisht përfshin bashkimin e ndryshimeve në një degë të përbashkët të kontrollit të versioneve. Pjesa e dytë përgjithësisht përfshin procese të automatizuara duke përfshirë: ndërtimin, testimin dhe shumë procese të tjera.
Zakonisht, një server ndërton nga zona e integrimit shpesh, p.sh. pas çdo kryerjeje ose periodikisht, si një herë në ditë. Serveri mund të kryejë kontrolle të kontrollit të cilësisë, siç është ekzekutimi i testeve të njësisë dhe të mbledhë metrika të cilësisë së softuerit nëpërmjet proceseve të tilla si analiza statike dhe testimi i performancës.
Automatizimi i ndërtimit
Automatizimi i ndërtimit konsiderohet si një praktikë më e mirë në zhvillimin e softuerëve. Mjetet e automatizimit të ndërtimit përdoren për të automatizuar ndërtimin.
Përkrahësit e CI rekomandojnë që një komandë e vetme duhet të ketë aftësinë për të ndërtuar sistemin.
Automatizimi shpesh përfshin automatizimin e integrimit, i cili shpesh përfshin vendosjen në një mjedis të ngjashëm me prodhimin. Në shumë raste, skripti i ndërtimit jo vetëm që përpilon skedarë binare, por gjeneron edhe dokumentacion, faqe interneti, statistika dhe media shpërndarjeje (siç janë skedarët Debian DEB, Red Hat RPM ose Windows MSI).
Komitetet atomike
CI kërkon që sistemi i kontrollit të versioneve të mbështesë commit-et atomike; me fjalë të tjera, të gjitha ndryshimet e një zhvilluesi trajtohen si një commit i vetëm.
Kryerja e ndryshimeve
Kur bën një ndryshim në kod, një zhvillues krijon një degë që është një kopje e bazës aktuale të kodit. Ndërsa ndryshimet e tjera ruhen në depo, kjo kopje ndryshon nga versioni më i fundit.
Sa më gjatë të vazhdojë zhvillimi në një degë pa u bashkuar me degën e integrimit, aq më i madh është rreziku i konflikteve dhe dështimeve të shumëfishta të integrimit kur dega e zhvilluesit përfundimisht bashkohet përsëri. Kur zhvilluesit paraqesin kod në depo, ata së pari duhet të përditësojnë kodin e tyre për të pasqyruar ndryshimet në depo që kur kanë marrë kopjen e tyre. Sa më shumë ndryshime të përmbajë depoja, aq më shumë punë duhet të bëjnë zhvilluesit përpara se të paraqesin ndryshimet e tyre.
Përfundimisht, depoja mund të bëhet aq e ndryshme nga linjat bazë të zhvilluesve saqë ata hyjnë në atë që nganjëherë quhet "ferr bashkimi" ose "ferr integrimi", ku koha që duhet për t'u integruar tejkalon kohën që u desh për të bërë ndryshimet e tyre origjinale.
Testimi në nivel lokal
- Përkrahësit e CI sugjerojnë që zhvilluesit duhet
- përdorin zhvillim të bazuar në testime dhe
Sigurohuni që të gjitha testet e njësisë të kalojnë lokalisht përpara se t'i kryeni ato në degën e integrimit, në mënyrë që puna e një zhvilluesi të mos prishë kopjen e një zhvilluesi tjetër.
Karakteristikat e papërfunduara mund të çaktivizohen para kryerjes së tyre, duke përdorur butonat e çaktivizimit të karakteristikave.
Dorëzim i vazhdueshëm dhe vendosje e vazhdueshme
Dorëzimi i vazhdueshëm siguron që softueri i kontrolluar në një degë integrimi është gjithmonë në një gjendje që mund t'u vendoset përdoruesve, dhe vendosja e vazhdueshme automatizon procesin e vendosjes.
Dorëzimi i vazhdueshëm dhe vendosja e vazhdueshme shpesh kryhen së bashku me CI dhe së bashku formojnë një tubacion CI/CD.
Kontrolli i versionit
Përkrahësit e CI rekomandojnë ruajtjen e të gjithë skedarëve dhe informacionit të nevojshëm për ndërtimin e kontrollit të versioneve (për git një depo), dhe që sistemi duhet të jetë i ndërtueshëm nga një arkëtim i ri dhe të mos kërkojë varësi shtesë.
Martin Fowler rekomandon që të gjithë zhvilluesit të angazhohen në të njëjtën degë integrimi.
Kryej shpesh
Zhvilluesit mund ta zvogëlojnë përpjekjen për zgjidhjen e ndryshimeve kontradiktore duke i sinkronizuar ndryshimet me njëra-tjetrën shpesh, të paktën çdo ditë. Kontrollimi i punës së një jave rrezikon konfliktin si në gjasat e ndodhjes ashtu edhe në kompleksitetin e zgjidhjes. Konfliktet relativisht të vogla janë dukshëm më të lehta për t'u zgjidhur sesa ato më të mëdha. Integrimi (kryerja) e ndryshimeve të paktën një herë në ditë konsiderohet praktikë e mirë, dhe më shpesh më e mirë.
Ndërtim i përditshëm
Ndërtimi çdo ditë, nëse jo më shpesh, në përgjithësi rekomandohet.
Çdo angazhim duhet të ndërtohet
Sistemi duhet të ndërtojë lidhje (commits) në versionin aktual funksional për të verifikuar që ato integrohen saktë. Një praktikë e zakonshme është përdorimi i Integrimit të Vazhdueshëm Automatik, megjithëse kjo mund të bëhet manualisht. Integrimi i vazhdueshëm automatik përdor një server ose daemon integrimi të vazhdueshëm për të monitoruar sistemin e kontrollit të rishikimit për ndryshime, pastaj ekzekuton automatikisht procesin e ndërtimit.
Çdo commit për korrigjimin e gabimeve duhet të vijë me një rast prove.
Kur rregulloni një gabim, është praktikë e mirë të shtyni një rast testimi që e riprodhon gabimin. Kjo parandalon që korrigjimi të kthehet mbrapsht dhe gabimi të rishfaqet, gjë që njihet si regres.
Mbajeni ndërtimin shpejt
Ndërtimi duhet të përfundojë shpejt në mënyrë që nëse ka ndonjë problem me integrimin, ai të identifikohet shpejt.
Testoni në një klon të mjedisit të prodhimit
Të kesh një mjedis testimi mund të çojë në dështime në sistemet e testuara kur ato vendosen në mjedisin e prodhimit, sepse mjedisi i prodhimit mund të ndryshojë ndjeshëm nga mjedisi i testimit. Megjithatë, ndërtimi i një replike të një mjedisi prodhimi është i kushtueshëm. Në vend të kësaj, mjedisi i testimit ose një mjedis i veçantë para-prodhimi ("staging") duhet të ndërtohet për të qenë një version i shkallëzueshëm i mjedisit të prodhimit për të lehtësuar kostot duke ruajtur përbërjen dhe nuancat e pirgut të teknologjisë. Brenda këtyre mjediseve të testimit, virtualizimi i shërbimit përdoret zakonisht për të marrë akses sipas kërkesës në varësi (p.sh., API, aplikacione të palëve të treta, shërbime, mainframe, etj.) që janë përtej kontrollit të ekipit, ende në zhvillim ose shumë komplekse për t'u konfiguruar në një laborator virtual testimi.
Bëjeni të lehtë marrjen e rezultateve më të fundit
Vënia e versioneve të gatshme në dispozicion të palëve të interesuara dhe testuesve mund të zvogëlojë sasinë e ripërpunimit të nevojshëm gjatë rindërtimit të një veçorie që nuk i plotëson kërkesat. Përveç kësaj, testimi i hershëm zvogëlon shanset që defektet të mbijetojnë deri në vendosje. Gjetja e gabimeve më herët mund të zvogëlojë sasinë e punës së nevojshme për t'i zgjidhur ato.
