Gyors és egyszerű CI/CD csővezetékek bármilyen nyelv vagy eszköz szemantikai verziójával. Az eszköz új verziójának kiadásának unalmasnak kell lennie. Nincs szertartás, nincs ütemezés, nem is beszélgetés. Átláthatónak, könnyűnek, megbízhatónak, sőt informatívnak kell lennie – erről később bővebben. Mindazonáltal, mint szoftver tanácsadó, aki segít a csapatoknak a DevOps megoldások végrehajtásában, gyakran úgy találom, hogy ez nem így van. Ahhoz, hogy megértsem a perspektívámat, szeretném megosztani, hogy a témával kapcsolatos nézeteim az évek során hogyan fejlődtek. Jelenleg olyan folyamatot alkalmazok, amely magában foglalja a moduláris munkafolyamatok „LEGO blokkjainak” elrendezését kisebb módosításokkal, például paraméterváltozásokkal. Például a Rust X könyvtár építési folyamata valószínűleg megegyezik a Rust Y könyvtárával, és a Node szerver foo valószínűleg megegyezik a Node szerver sávjával. Az évek során megpróbáltam nyílt forráskódú alkatrészeket összeállítani, hogy ezt elérjem, de soha nem találtam meg a megfelelő kombinációt. De először... Tudom, hogy a verziózás és a kiadás nem a legizgalmasabb témák; azonban ez egy olyan probléma, amellyel minden projekt szembesül, még akkor is, ha vibe-kódolva van (valószínűleg különösen!). Ha helyesen csinálod, a projekted sokkal professzionálisabbnak tűnik, és a felhasználóknak is kommunikál a változásokkal, ez pedig nagyobb bizalmat teremt a projektekben, mivel segít a fejlesztőknek az új változások világos és következetes megértésében és elfogadásában. Kezdetben... A szoftverfejlesztési pályafutásom kezdetén a kiadások meglehetősen események voltak.Ezek a mérföldkövek melléktermékei voltak, amelyek egy sor sprint révén valósultak meg, mindenkinek a legjobb képességére tervezték, egy sor tervezési találkozón, ahol a hátrányt leküzdötték, és a méltó feladatokat választották ki. Minden tőlünk telhetőt megteszünk, hogy leírjuk a terv specifikációját, és becsüljük meg a Fibonacci számot vagy a póló méretét, vagy a legrosszabb esetben a napok számát. A kiadás volt a csúcspontja ennek a folyamatnak. a kézbesíthető, szállított a valódi felhasználóknak. Mivel a csúcspontja ennek a folyamatnak, és nagy a tét, hogy helyesen, a kiadás egy érzelmi pillanat volt. Az izgalmas? A félelem? Talán néhányan, akiket kiváltottál, a szívedben versenyeztek, miközben a gépeket mozgásba helyezték. Van még a részletesség és a dráma a verziószám eldöntése. Ez egy nagy kiadás? Egy teljesen új verzió?? Kisebb? Patch? Néha a marketing diktálta a verziót... 2.0! Ebben a szakaszban a karrierem, ez nagyrészt nem az én véleményem volt, hogy a téma a verziószámok, és visszatekintve, ez valószínűleg nem kellene senki (látni fogja, mit értem később). Nem voltam felelős a kiadásokért az elején... De... ez nem tart örökké. nyílt forráskódú A karrierem valamelyik szakaszában érdekelt, hogy hozzájáruljak a nyílt forráskódhoz. Általában npm modulok formájában, mivel akkoriban nagyon jól ismerem a Node-t. Én voltam a felelős a kiadásokért. Nem emlékszem, hogyan, talán néhány hírlevél vagy talán a NYC NodeJS találkozó részeként, amelyet Matt Walters és én együtt futottunk - találkoztam a könyvtárral. A Semantic Release egy olyan elvet hajtott végre, amellyel webfejlesztőként a szemantikán alapuló aggodalmak szétválasztására törekedtem. semantic-release Mielőtt elindulna és elkezdené használni a szemantikus kiadásokat, vannak korlátozások, amelyekkel találkoztam... És egy pillanat alatt eljutok hozzájuk. Először is, magas szinten, az alapötlet, hogy a szemantikus kiadás prédikált, hogy kövesse a kompromisszum üzeneteinek egy adott formátumát, és az üzenetek alapján a verzió kiszámítható. Beszélt az érzelmek eltávolításáról a kiadásokból, robotikusvá téve őket, attól függően, hogy mi változott valójában. Ha volt egy új nagy verzió kiadás – v2 v3, például, ez azt jelentette, hogy volt egy áttörő változás. Ahhoz, hogy ezt a kompromisszum üzenetében jelezze, tartalmaznia kell A kompromisszum testében. 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! A kisebb verzióütközések, például a v2.0.0 és a v2.1.0 között azt jelentették, hogy új funkciót adtak hozzá. 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. A patch verziók jelezték a javításokat, vagy a refaktorokat, vagy alapvetően bármi mást, ami új kiadást váltana ki. fix: revert "fix" by AI that skipped the breaking tests to avoid the failure És végül, néhány elkötelezettségnek egyáltalán nem szabad kiadni. „Munkák”, ahogyan bemutatkoztak nekem. chore: update release pipeline version from v3.1.0 to v3.1.1 Ez a speciális formátum a kompromisszum üzenetek ismert, mint Megnézheted az oldalukat a teljes specifikációért, de meg akartam osztani. Hagyományos bizottságok Továbbá, ez az információ tartalmazza a kötelezettségvállalások is megjelenhet a változás napló – például kiemeli a megszakító változás. 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. Tehát egy ideig a szemantikai kiadás nagyszerű volt számomra. A Node projektek számára még mindig... DevOps alkalmazások Mindig érdekelt az ötlet, hogyan kell építeni skálázható elosztott rendszerek, és így volt valami, amit folytattam egy jó ideje a karrieremben. hosszú történet rövid, végül megtanultam, hogyan kell csinálni jól, de volt egy új probléma: hogyan kell telepíteni az összes darabot. Ezek nem npm modulok voltak, hanem alkalmazások, szolgáltatások, adatbázisok és sorok! Imádtam a szemantikus kiadás egyszerűségét, de csak a Node.js projektek esetében működött jól. fájlokat nem csomópontos projektekbe, de ez a legjobb esetben zavaros és hacky volt. package.json Körülbelül ebben az időben mélyen részt vettem a DevOps-ben, a Jenkins korszakban, amikor a Docker elkezdett vonzódni. Megtanultam megírni a csővezetékeket a Jenkins-szel, és mindent elhelyezni a Docker Swarm segítségével! Korai DevOps utazásom és a Docker felfedezése a telepítéshez. A legújabb és még mindig releváns és pontos Guide to Git with Trunk Based Development cikk elmagyarázza, hogy miért és hogyan, ha érdekel. A legújabb és még mindig releváns és pontos Guide to Git with Trunk Based Development cikk elmagyarázza, hogy miért és hogyan, ha érdekel. Mindig is azt akartam, hogy ezeket a projekteket, amelyekkel dolgoztam, a szemantikus kiadási projektekhez hasonlóan verziózzák és bocsássák ki, de soha nem találtam olyan megoldást, amely szintén működött. Nem volt a legfontosabb dolog a listámon, ezért általában elég jónak neveztem, és a hibákkal éltem. Idővel, mint DevOps tanácsadó, találkoztam és kiadtam különböző projekteket több nyelven és keretrendszerben, és mindegyiknek szükségessé vált a verziózás, a kiadások és a változási naplók. Egy másik fejfájás, amellyel gyakran találkoztam, nagy, monolitikus csővezetékek voltak. A Jenkins korszakból származó, megkapom, így írtam a csővezetékeket is. Megpróbáltam a teljes kiadás áramlását egy nagy lépéssorozatban megtenni, kezdve a főhöz való nyomással. Ha a főhöz tolta, különböző minőségellenőrzések futnának, és egy új verziót építettek, közzétettek, címkéztek és kiadtak. Ez önmagában nem szörnyű, és a legtöbb esetben valószínűleg „elég jó”; azonban, mint egy DevOps tanácsadó, újra és újra meg kell csinálnom. A dolgokat kisebb, modulárisabb darabokra bontva lehetővé teszi, hogy ezek a darabok több projektet szolgáljanak. először hallottam ezt a hírhedt James Halliday, az AKA Substack, mint , egy olyan ötlet, amely az UNIX filozófiák elfogadásából származik. Az ötletek lefedettsége Például egy Node Quality pipeline lehet ugyanaz minden Node projektben, feltéve, hogy követi a szabványos npm script konvenciókat, és így egy általános csővezeték futtatásához, építéséhez és egység teszteléséhez megosztható a legtöbb, ha nem az összes Node.js projektben. és így tovább, valamint az írásbeli szakasz a A fájl meghatározza, hogy mi történik, ha A parancsnokság fut. npm run lint --if-present package.json lint Magas szintű csővezetékek verziózáshoz és kiadáshoz Magas szinten minden projekt, amelyet ki kell adni, először egy új verziószámmal lesz címkézve, majd létrehozhat egy olyan kiadást, amely ehhez a verziószámhoz kapcsolódik, és a kapcsolódó csővezetékek részeként műtárgyakat fognak előállítani. A GitHub-tevékenységeket leggyakrabban használom, mivel úgy gondolom, hogy a csővezetékek nyersanyagok, és ez egy egyszerű dolog, amivel elkezdhetem. sokan használtam, de mindegyik alapvetően ugyanaz - végezzen egy sor lépést egy megosztott kötetgel. A verziózás önmagában, ha a hagyományos kötelezettségvállalások szabványait követi a szemantikus verziónövelés, nem nyelvi-specifikus dolog. Hosszú ideig kötöttem a kiadásokat a verziókhoz, azt gondoltam, hogy ugyanazon dolog részét képezik, amikor valójában két külön entitás kapcsolódik össze. Ezek szétválasztása a csővezeték verziószerkezetét saját moduláris részévé tette, amely ezután kiváltotta a verzió felépítését és a későbbi kiadást. Hadd szakítsam le... Minden projekthez, a GitHub Actions-ban, két csővezetékem van: 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. Mint korábban említettem, miután többször megpróbáltam összerakni a nyílt forráskódú összetevőket a GitHub Actions Marketplace-ből, végül feladtam, és saját eszközt írtam, amely az első lépést kezeli. Bevezetés Következő Következő A vnext egy gyors Rust CLI-eszköz, amely hagyományos kompromisszumüzeneteket használ a következő szemantikus verzió kiszámításához, automatizálva a nagyobb, kisebb vagy patchütéseket a egyszerűsített kiadásokhoz. Itt van, hogyan kell használni. NEXT_VERSION=v`vnext` vnext --changelog > CHANGELOG.md Ez elég egyszerű!Hadd mondjam el, mit gondolsz. Teljesen a projekt git történelmén alapul. Nem számít, hogy milyen nyelvet vagy eszközt bocsát ki; a verziószerkesztési folyamat alapvetően ugyanaz. Szerezzen egy új verziót, frissítse néhány fájlban, hozzon létre egy changelogot, címkét és nyomja meg. Az egyetlen különbség az, hogy mely fájlokat kell frissíteni - ez számításba kerül a munkafolyamatban, amit egy pillanat alatt megosztok. Könnyen és gyorsan telepíthető a - az Ha be van állítva, akkor futtathatja: vnext ubi Az „Universal Binary Installer” ubi --project unbounded-tech/vnext Azt is létrehozott egy megosztott GitHub Akciók munkafolyamat, hogy hívja, amely kezeli az összes részletet. Íme, hogyan használhatja a megosztott munkafolyamatot: 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 Most projects will also need to configure how and which files to update with the new version number. jelenleg is, két generikus módszert támogat ( és Néhány nyelvi specifikus lehetőség. vnext yqPatches regexPatches A nyelvi-specifikus beállítások a legegyszerűbbek. két Használat A projekt csomagfájljainak frissítése. with.node true npm Használja az eszközt to patch specific fields in a YAML file. I often use this for updating version numbers in Helm charts: 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" Én is kihasználtam ezt a lehetőséget, hogy megosszam, hogyan kell egy személyes hozzáférési tokent használni egy telepítési kulcs helyett. Én is kihasználtam ezt a lehetőséget, hogy megosszam, hogyan kell egy személyes hozzáférési tokent használni egy telepítési kulcs helyett. Használat hogy megtalálja és helyettesítse az új verziószámot tartalmazó sorokat, például: 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 Az opciók kombinációját is használhatja. Egy árnyalat a GitHub-cselekvésekről Amikor egy műveletet futtat a GitHub Akciókon, a munkavállaló alapértelmezés szerint ideiglenes GitHub-hitelesítési tokent generál. Ez a token néhány alapvető feladat elvégzésére jogosult; azonban soha nem engedélyezett más csővezetékek kiváltására. De a következő lépés az új verzió címkézése után az volt, hogy egy másik csővezetéket indítsunk ezzel a címkével! Ne aggódj, ez a tervezés – egyszerűen egy intézkedés a GitHub, hogy megakadályozzák, hogy véletlenül forog egy csomó futók. Van néhány módja annak, hogy szándékos legyen - már két példát mutatok: A telepítési kulcs és a megfelelő GitHub Actions Secret használata Személyes hozzáférési token használata GitHub-tevékenységek titka GitHub alkalmazás létrehozása (elméletben – nem volt szükségem erre a lehetőségre) A személyes hozzáférési token használata kényelmes, ha Ön fizetős ügyfél a GitHub ökoszisztémában, mivel a szervezet egészére kiterjedő titkok állnak rendelkezésre. Az ingyenes szinten ez nem opció, így megmutatom, hogyan kell beállítani a telepítési kulcsot. Valójában nagyon egyszerűvé tettem azáltal, hogy a Ez egy nagyszerű lehetőség, mivel ha így van konfigurálva, nincs szükség emberi tudásra, és könnyen forgatható ugyanazon parancs újraindításával. vnext For each repository you want to set up a kiadáshoz egy telepítési kulcsot, a projekt könyvtárában... vnext First, get an auth token using A kulcsok kezelése engedélyével: gh gh auth refresh -h github.com -s admin:public_key -s admin:ssh_signing_key export GITHUB_TOKEN=$(gh auth token) Aztán a futás: vnext generate-deploy-key Lehet, hogy csodálkozol, nem megy ez magába a csővezetékbe? Sajnos nem találok módot arra, hogy automatizáljam ezt a lépést a Github Akciókban anélkül, hogy létrehoznám egy személyes hozzáférési tokent, mivel az alapértelmezett token nem tudja módosítani a Titkokat. Ez legyőzi a Deploy Key használata helyett az ingyenes szintet, mivel minden repo-ban létre kell hoznia. Lehet, hogy csodálkozol, nem megy ez magába a csővezetékbe? Sajnos nem találok módot arra, hogy automatizáljam ezt a lépést a Github Akciókban anélkül, hogy létrehoznám egy személyes hozzáférési tokent, mivel az alapértelmezett token nem tudja módosítani a Titkokat. Ez legyőzi a Deploy Key használata helyett az ingyenes szintet, mivel minden repo-ban létre kell hoznia. Ha a telepítési kulcs vagy a személyes hozzáférési token (PAT) a helyén van, és a futó verzió és címke munkafolyamat a törzságra tolja, a következő lépés a szabadon bocsátás! Ez projektenként változik, de mindegyiket az előző lépésben megjelölt verzió váltja ki. 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 }} Vagy ha ez egy Rust projekt lenne, talán valami ilyesmi: 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" Vagy ha ez egy Dockerfile alkalmazás, és a k8 erőforrás-definíciói a Gitops telepítésekhez, talán valami ilyesmi: 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 Megjegyzés: A telepítési kulcs nem nyomhatja meg a többi repost, például a gitops promóciós lépésben, így érdemes lehet a PAT használatát bárhol használni erre a repo-ra. Ha sok ilyen munkaterhelése van, a fizetett org-ra való frissítés érdemes lehet a szervezeti titkok számára, nem pedig minden repót külön-külön konfigurálni. Megjegyzés: A telepítési kulcs nem nyomhatja meg a többi repost, például a gitops promóciós lépésben, így érdemes lehet a PAT használatát bárhol használni erre a repo-ra. Ha sok ilyen munkaterhelése van, a fizetett org-ra való frissítés érdemes lehet a szervezeti titkok számára, nem pedig minden repót külön-külön konfigurálni. Generally, every release is a combination of some pieces of these similar modules, which do pretty much the same things but for their specific tools or languages. Általában a szervezetek legalább megpróbálnak követni sok ugyanazt a mintát az általuk létrehozott alkalmazások és szolgáltatások között, és így a munkafolyamatok megosztott moduláris darabokra való lebontása lehetővé teszi a fejlesztők számára, hogy meglehetősen egyszerűen csak másolják és illesszék ezeket a megosztott munkafolyamat-hívásokat minden ilyen típusú projektbe. Folyamatos kiadások a Changelogs segítségével Talán észrevetted, hogy egyfajta pillantást vetek a Vissza akartam térni erre, mivel ez egy érett kiadás folyamatának jelentős része.A changelog az, ahogyan kommunikálhatja a projekt változásait más fejlesztőknek. with.changelog A bumping verziókkal együtt a kompromisszum üzeneteket is használja a changelog létrehozásához, és egy CHANGELOG.md nevű fájlba mentheti, amely a verziótaggal és a verzióütközéssel együtt elkötelezett. vnext A fent megosztott kiadási munkafolyamatokban elrejtve ez a fájl a GitHub kiadás testét használja. A projekt maga: vnext Ez a kiadás egy patch verzió volt, mivel tartalmazott egy javítást, egy függőségi verzió bump formájában, és számos más feladatot. Ezeket a kiadási jegyzeteket ezután más eszközökben, például , egy olyan eszköz, amely a PR-eket a függőségek naprakésszé tételére teszi. felújítás A Pull Requests egyesítésekor szeretem használni a GitHub Squash és Merge funkcióját annak érdekében, hogy lehetőségem legyen egy szép végső kompromisszum üzenet címét és testét írni, amelyet a changelogban használnak. Például a Ahogyan a példában is láthatjuk, a teljes körű Markdown-ot a kompromisszum testként is elhelyezheti. Ez a Release Notes-ban megfelelően megjelenik! következtetés Tudom, hogy a verziózás és a kiadás nem a legszexisebb téma; meglehetősen unalmas - vagy inkább, meg kell! Ez azonban nem mindig így van, ezért hoztam létre És egy csomó Most már könnyedén felvehetem a legtöbb projektet nagyon gyorsan! vnext shared workflows Hopefully, it’s helpful for you too! Kérjük, tudassa velünk, ha ad És néhány megosztott munkafolyamatot is kipróbálok!Hálás lennék néhány csillagnak a GitHub-on és egy megosztásnak, ha hasznosnak találod őket! vnext
