Brze i jednostavne CI/CD cijevi s semantičkom verzijom za bilo koji jezik ili alat. Otvaranje nove verzije alata trebalo bi biti dosadno. Bez ceremonije, bez planiranja sastanaka, čak ni rasprave. To bi trebalo biti transparentno, besprijekorno, pouzdano, pa čak i informativno - više o tome kasnije. Međutim, kao softverski savjetnik koji pomaže timovima u provedbi DevOps rješenja, često shvaćam da to nije slučaj.Ono što nalazim varira divlje u kvaliteti, pa umjesto da vam kažem što mi se ne sviđa, usredotočimo se na to kako volim strukturirati svoje plinovode kako bih brzo i lako ugradio nove repozitorije. Da bih razumio svoju perspektivu, želio bih podijeliti kako su se moji pogledi na temu razvili tijekom godina. Trenutno, primjenjujem proces koji uključuje organiziranje "LEGO blokova" modularnih tokova rada s manjim prilagodbama, kao što su promjene parametara. Na primjer, proces izgradnje za knjižnicu Rust X vjerojatno je približno isti kao i knjižnica Rust Y, a Node server foo je vjerojatno približno isti kao Node server bar. Tijekom godina, pokušao sam sastaviti komponente otvorenog koda kako bih to postigao, ali nikada nisam našao sasvim pravu kombinaciju. Ali prvo... Shvaćam da verzija i izdavanje nisu najzanimljivije teme; međutim, to je problem s kojim se suočava svaki projekt, čak i kada je kodiran (vjerojatno posebno!). Ako to učinite ispravno, projekt će izgledati puno profesionalnije i komunicirati promjene svojim korisnicima.To uspostavlja više povjerenja u vaše projekte pomažući programerima da razumiju i usvoje nove promjene na jasan i dosljedan način. U početku... Oni su bili nusproizvod prekretnica, postignutih kroz niz sprinta, planiranih, na najbolji mogući način, u nizu sastanaka planiranja na kojima je prošao povratak i odabrani su zadaci koji su bili vrijedni. Učinili bismo sve što je u našoj moći da napišemo specifikaciju plana i procijenimo Fibonaccijev broj ili veličinu majice, ili u najgorem slučaju, nekoliko dana. Izlazak je bio vrhunac ovog procesa. isporuka isporučljivih, isporučena stvarnim korisnicima. Kao vrhunac ovog procesa, i visoke stave za dobivanje to ispravno, oslobađanje je bio emotivan trenutak. Što uzbudljivo? Šokantno ? Možda su neki od vas koji ste pokrenuli dobili vaše srce utrku dok su stavili strojeve u pokret. Tu je i detalj i drama odlučivanja o broju verzije. Je li ovo velika verzija?Cijela nova verzija??Majka?Patch? Ponekad je marketing diktirao verziju... 2.0! U ovom trenutku u mojoj karijeri, to u velikoj mjeri nije bilo moje mišljenje koje je važilo na ovu temu brojeva verzija, a gledajući unatrag, to vjerojatno ne bi trebalo biti nikoga (vidjet ćete što mislim kasnije). Nisam bio odgovoran za otpuštanja u početku... Međutim... to ne bi trajalo zauvijek. U otvorenom izvoru U nekom trenutku u mojoj karijeri, postao sam zainteresiran za doprinos otvorenog koda. općenito, u obliku npm modula, kao što sam bio vrlo u Node u to vrijeme. Bio je moj red biti odgovoran za oslobađanje. Ne sjećam se kako, možda kroz neki newsletter ili možda dio NYC NodeJS sastanka koji su Matt Walters i ja koristili zajedno - naišao sam na knjižnicu. Semantic Release je implementirao princip, s kojim sam vibrirala kao web developer, odvajanja briga na temelju semantike. semantic-release Prije nego što krenete i počnete koristiti semantičko oslobađanje, postoje neka ograničenja s kojima sam naišao... I doći ću do onih u trenutku. Prvo, na visokoj razini, osnovna ideja koju je semantičko puštanje propovijedao bila je da biste slijedili određeni format za vaše poruke o kompromisu, a na temelju poruka, verzija bi se mogla izračunati. Govorio je o uklanjanju emocija iz izdanja, čineći ih robotičnim, na temelju onoga što se zapravo promijenilo. Ako je došlo do nove glavne verzije - v2 do v3, na primjer, to je značilo da je došlo do revolucionarne promjene. Da biste to označili u poruci kompromisa, uključili biste U tijelu komisije. BREAKING CHANGE: feat: revamp user auth flow BREAKING CHANGE: Per Chad's "game-changer" vision in the 3am Slack rant, we've ditched the old auth system for a blockchain-based solution because "passwords are so 2024." Update your clients or enjoy the 500 errors! Manji poremećaji u verziji, poput v2.0.0 do v2.1.0, značili su da je dodana nova značajka. feat: add dark mode toggle Per the 47-comment thread in the "urgent" ticket, users can now save their retinas. Dark mode added, but brace for the inevitable "make it darker" feedback. Patch verzije signalizirale su popravke, ili refaktore, ili uglavnom sve drugo što bi trebalo izazvati novo izdanje. fix: revert "fix" by AI that skipped the breaking tests to avoid the failure I na kraju, neki angažmani ne bi trebali izazvati oslobađanje uopće. „Posao“ kao što su mi predstavljeni. chore: update release pipeline version from v3.1.0 to v3.1.1 Ovaj specifični format poruka kompromisa bio je poznat kao Možete provjeriti njihovu stranicu za punu specifikaciju, ali želio sam podijeliti njezino djelo. Konvencionalne komisije Nadalje, ove informacije sadržane u komitetima također bi se mogle pojaviti kao dnevnik promjena - kao što je naglašavanje promjena koje se mijenjaju. What's new in v2.0.0 * feat: remove deprecated API BREAKING CHANGE: the FooBar API that was deprecated. To upgrade, you can use the new BazBar API. Dakle, za neko vrijeme, semantičko objavljivanje bilo je sjajno za mene. Korištenje DevOps Uvijek sam bio zainteresiran za ideju o tome kako izgraditi skalabilne distribuirane sustave, pa je to nešto što sam tražio već neko vrijeme u svojoj karijeri. To nisu bili npm moduli; to su bile aplikacije, usluge, baze podataka i redovi! Volio sam jednostavnost semantičkog objavljivanja, ali to je dobro funkcioniralo samo za Node.js projekte. datoteka na projekte koji nisu čvorovi, ali to je u najboljem slučaju bilo zbunjujuće i hacky. package.json Oko tog vremena, postao sam duboko uključen u DevOps, tijekom Jenkins ere, dok je Docker počeo dobiti privlačnost. Naučio sam pisati cijevi s Jenkinsom i implementirati sve s Docker Swarmom! Moje rano DevOps putovanje i otkriće Docker za ugradnju. Moj najnoviji i još uvijek relevantni i točni vodič za Git with Trunk Based Development članak objašnjava zašto i kako, ako ste zainteresirani. Također sam u to vrijeme prihvatio razvoj temeljen na trupu, i Moj najnoviji i još uvijek relevantni i točni Članak objašnjava zašto i kako, ako ste zainteresirani. Obveza za majstora Priručnik za razvoj temeljen na Trunk-u Oduvijek sam želio da ti projekti s kojima sam radio budu verzije i objavljeni kao što su projekti za izdavanje semantike, ali nikada nisam našao rješenje koje bi također funkcioniralo. To nije bila najvažnija stvar na mojoj listi, pa sam ga općenito nazvao dovoljno dobrim i živio s nedostatcima. Tijekom vremena, kao DevOps savjetnik, susreo sam i objavio razne projekte na više jezika i okvira, a svaki od njih je zahtijevao verziju, izdanja i changeloge. Još jedna glavobolja s kojom sam se često susreo bile su velike, monolitne cijevi. Dolazeći iz Jenkinsove ere, dobio sam to, to je način na koji sam također koristio pisanje cijevi. Pokušao bih imati cijeli protok oslobađanja u velikoj seriji koraka, počevši od guranja do glavnog. Ako ste gurnuti do glavnog, različite provjere kvalitete bi se pokrenule, a nova verzija bi bila izgrađena, objavljena, označena i objavljena. To nije strašno samo po sebi i vjerojatno je "dovoljno dobro" u većini slučajeva; međutim, kao DevOps savjetnik, moram to učiniti više puta. Razbijanje stvari na manje, modularnije dijelove omogućuje tim dijelovima da služe više projekata. , ideja koja dolazi od prihvaćanja UNIX filozofija. Pokrivanje ideja Na primjer, Node Quality pipeline može biti isti u svakom Node projektu, pod pretpostavkom da slijedite standardne konvencije npm skripta, pa se generički pipeline za pokretanje vezivanja, izgradnju i testiranje jedinica može podijeliti na većini, ako ne i na svim Node.js projektima. I tako dalje, kao i u odjeljku o datoteka određuje što se događa kada se to Zapovjedništvo je u tijeku. npm run lint --if-present package.json lint Pipelines na visokoj razini za verziju i izdavanje Na visokoj razini, svaki projekt koji treba biti objavljen najprije će biti označen novim brojem verzije. Koristim GitHub Actions najčešće, jer mislim da su pipelines roba, a to je jednostavno početi s. Koristio sam mnoge, ali oni su svi u osnovi isti - izvršite niz koraka s zajedničkim volumenom. Sama verzija, ako slijedimo standard konvencionalnih obveza vezanih uz semantičko povećanje verzije, nije jezično specifična stvar. Dugo sam vezivao izdanja na verzije, misleći da su dio iste stvari, dok su u stvarnosti dvije različite entitete spojene zajedno. Razdvajanje ih odvojeno učinilo je dio verzije plinovoda vlastitim modularnim dijelom, što je zatim izazvalo izgradnju te verzije i naknadno objavljivanje. Za svaki projekt, u GitHub akcijama, imam dvije pipeline: On commit to the trunk branch, version, and tag When a commit occurs in the trunk branch (usually or ), trigger a pipeline that runs quality checks, and, if they pass, calculates a new version number. It then creates and pushes a tag with that new version number. We can also use this opportunity to update that version number in the code base if necessary, and generate a change log from the commit data that was used to calculate the new version number. main master When a tag is created, build new versions and release them. This step is simplified by the previous step of doing the version bump. Everything’s already been bumped to the new version. We can just run build and release using the tag as the base. Kao što sam ranije spomenuo, nakon što sam mnogo puta pokušao spojiti komponente otvorenog koda s GitHub Akcijskog tržišta, na kraju sam odustao i napisao svoj vlastiti alat koji rješava korak jedan. Uvođenje Sljedeći Sljedeći vnext je brz Rust CLI alat koji koristi konvencionalne poruke kompromisa za izračunavanje vaše sljedeće semantičke verzije, automatizirajući glavne, manje ili patch bumpe za racionalizirana izdanja. Evo kako ga koristiti. NEXT_VERSION=v`vnext` vnext --changelog > CHANGELOG.md Mislim da je to prilično jednostavno!Daj mi znati što misliš. U potpunosti se temelji na git povijesti projekta. Nije važno koji jezik ili alat objavljujete; proces izdavanja verzija je u osnovi isti. Dobijte novu verziju, ažurirajte je u nekim datotekama, kreirajte changelog, tag i push. Jedina razlika je u tome koje datoteke treba ažurirati - to se računa u toku rada koji ću dijeliti u trenutku. Brzo i jednostavno instalirati preko – Nakon konfiguriranja, možete pokrenuti: vnext ubi Sljedeći članakUniversal Binary Installer ubi --project unbounded-tech/vnext Također sam stvorio zajednički GitHub Actions tok posla koji možete nazvati, koji se bavi svim tim detaljima. Evo kako koristiti zajednički tok posla: name: On Push Main, Version and Tag on: push: branches: - main - master permissions: packages: write contents: write jobs: version-and-tag: uses: unbounded-tech/workflow-vnext-tag/.github/workflows/workflow.yaml@v1 with: useDeployKey: true changelog: true Većina projekata također će morati konfigurirati kako i koje datoteke ažurirati s novim brojem verzije. Trenutno je, Podržava dvije generičke metode ( i i nekoliko jezičnih opcija. vnext yqPatches regexPatches Opcije specifične za jezik najjednostavnije su za korištenje. dva Koristi ažurirati paket datoteke projekta. with.node true npm Koristite alat Često koristim ovo za ažuriranje brojeva verzija u Helm grafikonima: yqPatches yq version-and-tag: uses: unbounded-tech/workflow-vnext-tag/.github/workflows/workflow.yaml@v1.13.0 secrets: GH_PAT: ${{ secrets.YOUR_ORG_SECRET_PAT }} with: usePAT: true changelog: true yqPatches: | patches: - filePath: helm/values.yaml selector: .image.tag valuePrefix: "v" - filePath: helm/Chart.yaml selector: .version valuePrefix: "v" Također sam iskoristio ovu priliku da podijelim kako koristiti osobni token za pristup umjesto ključa za postavljanje. Također sam iskoristio ovu priliku da podijelim kako koristiti osobni token za pristup umjesto ključa za postavljanje. Koristi Pronađite i zamijenite niz s novim brojem verzije. na primjer: regexPatches sed regexPatches: | patches: - filePath: package/composition.yaml regex: /ghcr.io/org-name/package-name:(.*)/g valuePrefix: ghcr.io/org-name/package-name:v - filePath: README.md regex: /Current version: v[0-9]+\.[0-9]+\.[0-9]+/g valuePrefix: Current version: v Također možete koristiti kombinaciju opcija. Nuance o GitHub akcijama Kada pokrenete akciju na GitHub Actionsu, podrazumijeva se da radnik generira privremeni token za autentifikaciju GitHub. Ovaj token ima dozvolu za obavljanje nekoliko osnovnih zadataka; međutim, nikad nije dopušteno pokrenuti druge cijevi. Ali naš sljedeći korak nakon označavanja nove verzije bio je pokrenuti još jedan kanal s tim oznakom! Nemojte se brinuti, to je po dizajnu - jednostavno mjera GitHub-a kako bi se spriječilo nenamjerno okretanje gomile trkača. Postoji nekoliko načina da budete namjerni o tome - već sam pokazao primjer od dva: Korištenje ključa za ugradnju i odgovarajuće GitHub akcije tajna Korištenje osobnog tokena za pristup kao GitHub akcijske tajne Stvaranje GitHub aplikacije (teoretski – nisam imao potrebu za ovom opcijom) Korištenje osobnog tokena pristupa prikladno je ako ste plaćeni klijent u GitHub ekosustavu, jer su dostupne tajne za cijelu organizaciju. Na besplatnoj razini, to nije opcija, pa ću vam pokazati kako postaviti ključ za ugradnju umjesto toga. U stvari, učinio sam to vrlo jednostavnim izgradnjom u To je sjajna opcija, jer kada je konfigurirana na ovaj način, čovjek ne mora znati, a može se lako rotirati tako što će ponovno pokrenuti istu komandu. vnext Za svaki repozitorij koji želite postaviti za otpuštanje s ključem za ugradnju, u direktoriju projekta... vnext Prvo, dobijte auth token pomoću S dopuštenjem za upravljanje ključima: gh gh auth refresh -h github.com -s admin:public_key -s admin:ssh_signing_key export GITHUB_TOKEN=$(gh auth token) Nakon toga trči: vnext generate-deploy-key Možda se pitate, ne može li to ići u samu cijev? Nažalost, ne mogu naći način da automatiziram ovaj korak u Github akcijama bez stvaranja osobnog tokena za pristup, jer podrazumijevani token ne može mijenjati tajne. Ovo pobjeđuje pupose korištenja ključa za razmjenu umjesto u slobodnom razredu, jer biste ga trebali stvoriti u svakom repo-u. Možda se pitate, ne može li to ići u samu cijev? Nažalost, ne mogu naći način da automatiziram ovaj korak u Github akcijama bez stvaranja osobnog tokena za pristup, jer podrazumijevani token ne može mijenjati tajne. Ovo pobjeđuje pupose korištenja ključa za razmjenu umjesto u slobodnom razredu, jer biste ga trebali stvoriti u svakom repo-u. S vašim ključem za ugradnju ili osobnim tokenom za pristup (PAT) na mjestu, a radni tijek verzije i oznake koji se pokreće na vašoj granici, sljedeći korak je oslobađanje! To će varirati po projektu, ali svi su pokrenuti verzijom koja je označena iz prethodnog koraka. name: On Version Tag, Trigger GitHub Release on: push: tags: - 'v*.*.*' permissions: contents: write jobs: release: uses: unbounded-tech/workflow-simple-release/.github/workflows/workflow.yaml@v1 with: tag: ${{ github.ref_name }} name: ${{ github.ref_name }} Ili, ako je to bio projekt Rust, možda nešto ovako: name: On Version Tagged, Build and Publish Rust Binaries on: push: tags: - "v*.*.*" permissions: contents: write jobs: build-and-release: uses: unbounded-tech/workflows-rust/.github/workflows/release.yaml@v1 with: binary_name: ${{ github.event.repository.name }} build_args: "--release --features vendored" Ili, ako je riječ o aplikaciji s Dockerfile-om i definicijama resursa za Gitopsove implementacije, možda nešto ovako: name: promote on: push: tags: - v*.*.* permissions: contents: write packages: write issues: write pull-requests: write jobs: publish: uses: unbounded-tech/workflows-containers/.github/workflows/publish.yaml@v1.1.1 release: needs: publish uses: unbounded-tech/workflow-simple-release/.github/workflows/workflow.yaml@v1 with: tag: ${{ github.ref_name }} name: ${{ github.ref_name }} promote: needs: release uses: unbounded-tech/workflows-gitops/.github/workflows/helm-promote.yaml@v1 secrets: GH_PAT: ${{ secrets.GH_PAT }} with: environment_repository: your-org/staging-env path: .gitops/deploy project: staging Napomena: Ključ za ugradnju ne može pritisnuti na drugi repos, kao što je u koraku gitops promocije, tako da možete razmotriti korištenje PAT-a svugdje za ovaj repository. Napomena: Ključ za ugradnju ne može pritisnuti na drugi repos, kao što je u koraku gitops promocije, tako da možete razmotriti korištenje PAT-a svugdje za ovaj repository. Općenito, svako izdanje je kombinacija nekih komada tih sličnih modula, koji rade prilično iste stvari, ali za njihove specifične alate ili jezike. Obično organizacije barem pokušavaju slijediti mnoge iste obrasce u svim aplikacijama i uslugama koje grade, pa tako razgradnja tokova rada na zajedničke modularne dijelove omogućuje programerima da gotovo jednostavno kopiraju i prilepe svoj okus tih zajedničkih poziva na tokove rada na svaki projekt te vrste. Dosljedno objavljivanje s Changelogovima Možda ste primijetili da sam nekako pogledao preko Želio sam se vratiti na to, jer je to značajan dio procesa zrelog objavljivanja.Changelog je kako možete komunicirati načine na koje se vaš projekt promijenio drugim programerima. with.changelog Uz bumping verzije, Također koristi poruke kompromisa kako bi konstruirao ovaj changelog i sačuvao ga u datoteku pod nazivom CHANGELOG.md, koja je angažirana zajedno s oznakom verzije i bumpsom verzije. vnext Sakriven u tim radnim tokovima izdanja koje sam dijelio gore, ova datoteka se koristi kao tijelo izdanja GitHub-a. Sam projekt: vnext Ovo izdanje bilo je patch verzija, jer je sadržalo popravak, u obliku ovisnosti o verziji, i niz drugih zadataka. Te bilješke oslobađanja zatim se pojavljuju u drugim alatima, kao što su , alat koji čini PR-ove kako bi vaše ovisnosti bile ažurirane. obnoviti Prilikom spajanja Pull zahtjeva, volim koristiti funkciju Squash i Merge GitHuba kako bih imao priliku napisati lijep naslov i tijelo konačne poruke o kompromisu koja će se koristiti u changelogu. Na primjer: Kao što je prikazano u primjeru, možete staviti punopravni Markdown kao tijelo kompromisa. Conclusion Znam da verzija i izdavanje nije najseksi tema; to je prilično dosadno - ili bolje, to bi trebalo biti! Međutim, to nije uvijek slučaj.To je razlog zašto sam stvorio i gomilu od Sada mogu lako pokrenuti većinu projekata vrlo brzo! vnext Zajednički tokovi rada Nadam se da će i vama biti korisno! Molim vas da me obavijestite ako dajete Ja bih cijenio neke zvijezde na GitHubu i dijeljenje ako ih nađete korisne! vnext
