Herhangi bir dil veya araç için semantik versiyonlama ile hızlı ve kolay CI/CD borular. Bir araçın yeni bir sürümünü yayınlamak sıkıcı olmalıdır. Hiçbir tören, toplantı planlaması, hatta bir tartışma bile olmamalıdır. Daha sonra daha fazla bilgi için şeffaf, çabucak, güvenilir ve hatta bilgilendirici olmalıdır. Bununla birlikte, ekiplere DevOps çözümlerini uygulamak için yardımcı olan bir yazılım danışmanı olarak, sık sık bunun böyle olmadığını buldum.Kalitede çok farklı buldum, bu yüzden sevmediğim şeyleri söylemek yerine, yeni depoları hızlı ve kolay bir şekilde yüklemek için borularımı nasıl yapılandırmayı sevdiğime odaklanalım. Bakış açımı anlamak için, konuyla ilgili görüşlerimin yıllar içinde nasıl geliştiğini paylaşmak istiyorum.Şu anda, parametre değişiklikleri gibi küçük ayarlarla modüler iş akışlarının “LEGO bloklarını” düzenlemeyi içeren bir süreç uyguluyorum.İdeal olarak, aynı türde paylaştıkları zaman bir projenin aynı inşaat bloklarını basitçe kopyalamak ve yapıştırmamı sağlayan varsayılanları hedefliyorum. Örneğin, Rust Kütüphanesi X için oluşturma işlemi muhtemelen Rust Kütüphanesi Y ile aynıdır ve Node sunucu foo muhtemelen Node sunucu çubuğu ile aynıdır. Yıllar boyunca, bunu başarmak için açık kaynaklı bileşenleri monte etmeye çalıştım, ancak hiç doğru kombinasyonu bulamadım. Ama önce... Versiyonlama ve yayınlama en heyecan verici konulardan biri olmadığını anlıyorum; ancak, vibe kodlandığında bile (muhtemelen özellikle!). Bunu doğru yaparak projeyi daha profesyonel görünecek ve kullanıcılarına değişiklikleri iletecektir.Bu, geliştiricilerin yeni değişiklikleri net ve tutarlı bir şekilde anlamalarına ve kabul etmelerine yardım ederek projelerinize daha fazla güven oluşturur. Başlangıçta... Yazılım mühendisliği kariyerimin başlangıcında, yayınlar oldukça önemli bir olaydı. Bir dizi sprint yoluyla gerçekleştirilen, planlanan, herkesin en iyisini yapabileceği bir dizi planlama toplantısında, gerilimin geçildiği ve değerli görevlerin seçildiği bir dizi toplantıdan yan ürünlerdi. Planın bir spesifikasyonunu yazmak ve Fibonacci numarasını veya T-Shirt boyutunu tahmin etmek için elimizden gelenin en iyisini yaparız, ya da en kötü durumda, birkaç gün. Yayınlanma, bu sürecin zirvesiydi. teslim edilebilirlerin teslimatı, gerçek kullanıcılara gönderildi. Bu sürecin zirvesiydi ve düzeltilmesi için yüksek bahisler olduğu için, serbest bırakma duygusal bir andı. Heyecanlı mı ? Korkuyor mu ? Belki de yarattığınız birkaç şey, makineleri harekete geçirirken kalbinizi yarıştı. Ayrıca bir versiyon numarasını belirlemek için detay ve drama da vardır. Bu büyük bir sürüm mü? Tamamen yeni bir sürüm? Minor? Patch? Bazen pazarlama versiyonunu dikte ediyor... 2.0! Kariyerimdeki bu noktada, bu versiyon sayıları konusundaki görüşüm önemli değildi ve geriye baktığımızda, muhtemelen kimseye ait olmamalıydı (daha sonra ne demek istediğimi göreceksiniz). Ben başlangıçta yayınlar için sorumlu değildim... Ancak... bu sonsuza dek sürmeyecekti. Açık Kaynak Kariyerimin bir noktasında, açık kaynaklara katkıda bulunmakla ilgileniyordum. genellikle npm modülleri şeklinde, o zaman Node'a çok yaklaştığım için. Serbest bırakma sorumluluğumdan geçtim. Nasıl hatırlamıyorum, belki de bazı bültenler veya belki de Matt Walters ile birlikte çalıştığım NYC NodeJS toplantısının bir parçası - kütüphaneye rastladım. Semantic Release, bir web geliştiricisi olarak, semantik temelinde endişeler ayırma prensibini uyguladı. semantic-release Dışarı çıkıp semantik yayın kullanmaya başlamadan önce, bununla karşılaştığım bazı kısıtlamalar var... Ve bir an içinde bunlara ulaşacağım. İlk olarak, yüksek düzeyde, semantik sürümün vaftiz ettiği temel fikir, komite mesajlarınız için belirli bir formata uymak ve mesajlara dayanarak, sürüm hesaplanabilirdi. Gerçekte neyin değiştiğini temel alarak, yayınlardan duyguların kaldırılmasını, bunları robotik hale getirdiklerini söylüyordu. Örneğin, v2 ile v3 arasındaki yeni büyük bir sürüm sürümü varsa, bu önemli bir değişiklik anlamına geliyordu. Bunu komut mesajınızda ifade etmek için, Komisyonun vücudu içinde. 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! V2.0.0 ile v2.1.0 gibi küçük sürüm baskınları, yeni bir özellik eklendiğini ifade etti. 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 sürümleri, düzeltmeleri veya refaktorları ya da yeni bir sürümü tetikleyecek diğer her şeyi işaret etti. fix: revert "fix" by AI that skipped the breaking tests to avoid the failure Ve son olarak, bazı taahhütler hiç bir şekilde serbest bırakılmamalıdır. “Şirketler”, bana tanıtıldığı gibi. chore: update release pipeline version from v3.1.0 to v3.1.1 Bu özel mesaj biçimi olarak bilinir. Tüm özellikleri için sayfalarını kontrol edebilirsiniz, ancak bu özellikleri paylaşmak istedim. Geleneksel Komisyonlar Buna ek olarak, komisyonlarda yer alan bu bilgiler aynı zamanda bir değişiklik günlüğü olarak da görüntülenebilir - örneğin, kırıcı bir değişiklik vurgulamak gibi. 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. Yani, bir süre için, semantik yayın benim için harika oldu. Node projeleri için, hala... Ancak... DevOps için Ben her zaman genişletilebilir dağıtılmış sistemler oluşturma fikri ile ilgilendi ve bu yüzden kariyerimde oldukça uzun bir süre takip ettiğim bir şeydi. uzun hikaye kısa, sonunda bunu iyi nasıl yapacağımı öğrendim, ama yeni bir sorun vardı: tüm parçaları nasıl dağıtılır. Bunlar npm modülleri değildi; bunlar uygulamalar, hizmetler, veritabanları ve sıraydı! Semantik sürümün basitliğini sevdim, ancak sadece Node.js projeleri için iyi çalıştı. dosya olmayan düğüm projelerine, ama en iyisi karışık ve hacklidir. package.json Bu süre zarfında, Docker'ın çekim kazanmaya başladığı Jenkins çağında, DevOps'e derinden dahil oldum. Jenkins ile boru hattı yazmayı ve Docker Swarm ile her şeyi dağıtmayı öğrendim! İlk DevOps yolculuğum ve dağıtım için Docker'ı keşfettim. Ben de o zamanlarda çerçeve tabanlı geliştirmeyi kabul ediyordum ve ustalaşmaya taahhüt ettim. son ve hala ilgili ve doğru Git with Trunk Based Development makalesi ilgileniyorsanız bunun nedenini ve nasıl olduğunu açıklıyor. Ben de o zamanlarda çerçeve tabanlı geliştirmeyi kabul ediyordum ve ustalaşmaya taahhüt ettim. son ve hala ilgili ve doğru Git with Trunk Based Development makalesi ilgileniyorsanız bunun nedenini ve nasıl olduğunu açıklıyor. I always wanted these projects that I worked with to be versioned and released like semantic-release projects were, but I never found a solution that worked as well. Many wouldn’t be able to handle generating changelogs correctly, and some would sporadically bump the version wrong. Listemde en önemli şey değildi, bu yüzden genellikle yeterince iyi adlandırdım ve eksikliklerle yaşadım. Zamanla, bir DevOps danışmanı olarak, çeşitli dillerde ve çerçevelerde çeşitli projelerle karşılaştım ve yayınladım ve her biri versiyonlama, sürümler ve değişim günlükleri gerektirdi. Sık sık karşılaştığım başka bir baş ağrısı, büyük, monolitik borulardı. Jenkins çağından gelen, bunu elde ettim, bu da borular yazmak için kullandığım bir yoldur. Büyük bir dizi adımda tüm serbest bırakma akışına sahip olmaya çalışacağım, başlangıçta bir baskı ile başlarsınız. Eğer ana basarsanız, çeşitli kalite kontrolleri çalışacak ve yeni bir sürüm inşa edilecek, yayınlanacak, etiketlenecek ve yayınlanacak. Bu, kendiliğinden korkunç değildir ve çoğu durumda muhtemelen “yeterince iyi”; ancak bir DevOps danışmanı olarak, bunu tekrar tekrar yapmak zorundayım. şeyleri daha küçük, daha modüler parçalara bölmek, bu parçaların daha fazla projeye hizmet etmesine izin verir. UNIX felsefesini kabul etmekten kaynaklanan bir fikir. Fikirlerin Kapsamı Örneğin, bir Node Kalite boru hattı her Node projesinde aynı olabilir, standart npm senaryo sözleşmelerini takip ettiğinizi varsayarsak ve bu nedenle, bir boru hattı çalıştırmak, inşa etmek ve birim testleri için genel bir boru hattı çoğu, eğer tüm değilse, Node.js projelerinde paylaşılabilir. ve benzeri konularda yazarlık bölümleri, Dosya ne olduğuna karar verir Komutanlık çalışıyor npm run lint --if-present package.json lint Versioning ve Releasing için Yüksek Seviye Pipelines Daha sonra, bu sürüm numarasıyla ilişkili bir sürüm oluşturulabilir ve artifaktlar ilgili boruların bir parçası olarak üretilecektir. GitHub Eylemlerini en sık kullandım, çünkü boruların mal olduğunu düşünüyorum ve başlamak için basit bir şey. pek çok şeyi kullandım, ancak hepsi esasen aynıdır - paylaşılan bir hacimle bir dizi adım atın. Versiyonlama kendisi, eğer geleneksel komisyonların semantik bir versiyon artışına bağlı olduğu standartlarına uymak istiyorsak, dil spesifik bir şey değildir. Uzun süredir, sürümleri versiyonlara bağladım, aynı şeyin bir parçası olduklarını düşündüm, ama gerçekte iki ayrı varlık bir araya geldi. Bunları ayırarak, boru hattının versiyonlandırma kısmını kendi modüler parçası haline getirdi, bu da bu versiyonun bir yapısını ve sonraki sürümünü tetikledi. Her proje için, GitHub Eylemlerinde, iki boru hattım var: 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. Daha önce de belirttiğim gibi, GitHub Eylem Piyasası'ndan açık kaynaklı bileşenleri bir araya getirmeyi defalarca denedikten sonra, sonunda teslim oldum ve ilk adımı ele alan kendi aracımı yazdım. Giriş Sonraki Sonraki vnext, geleneksel komut mesajlarını kullanarak bir sonraki semantik sürümünüzü hesaplamak için hızlı bir Rust CLI aracıdır, akıllı sürümler için büyük, küçük veya düzeltme darbeyi otomatikleştirir. İşte nasıl kullanılacağı. NEXT_VERSION=v`vnext` vnext --changelog > CHANGELOG.md Bence çok basit! ne düşündüğünüzü söyleyin. Tamamen projenin git tarihine dayanmaktadır. Yayınladığınız dil veya araç önemli değil; sürümleme süreci temel olarak aynıdır. yeni bir sürüm alın, bazı dosyalarda güncelleyin, bir changelog, etiket oluşturun ve basın. tek fark hangi dosyaların güncellenmesi gerektiğidir - bu bir an içinde paylaşacağım iş akışında hesaplanır. Hızlı ve kolay bir şekilde kurulabilir - İÇİN Bir kez yapılandırıldıktan sonra, çalıştırabilirsiniz: vnext ubi “Universal Binary Installer” için yorumlar ubi --project unbounded-tech/vnext Ayrıca, tüm bu ayrıntıları ele alan bir paylaşılan GitHub Eylemler iş akışını da oluşturdum. Paylaşılan iş akışı nasıl kullanılır: 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 Çoğu proje de nasıl ve hangi dosyaları yeni sürüm numarası ile güncelleştirmek için yapılandırmak zorunda kalacaktır. Şu an için, İki farklı yöntemi destekler ( ve Birkaç farklı dil seçeneği vardır. vnext yqPatches regexPatches Dil belirli seçenekleri kullanmak için en kolay olanıdır. örneğin, İki Kullanım Projenin paket dosyalarını güncelleştirmek. with.node true npm aracı kullanın Bir YAML dosyasında belirli alanları düzeltmek için. genellikle Helm grafiklerinde sürüm numaralarını güncellemek için bunu kullanıyorum: 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" Bu fırsatı da kullanarak, bir dağıtım anahtarı yerine bir Kişisel Erişim Tokenini nasıl kullanacağımı paylaştım. Bu fırsatı da kullanarak, bir dağıtım anahtarı yerine bir Kişisel Erişim Tokenini nasıl kullanacağımı paylaştım. Kullanım Yeni versiyon numarası ile bir satır bulmak ve değiştirmek için. örneğin: 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 Seçeneklerin bir kombinasyonunu da kullanabilirsiniz. GitHub Eylemleri hakkında bir nüans GitHub Eylemleri'nde bir eylemi çalıştırdığınızda, işçi varsayılan olarak geçici bir GitHub kimlik doğrulama işareti oluşturur.Bu işaretin birkaç temel görevi gerçekleştirme izni vardır; ancak hiçbir zaman diğer boruların tetiklenmesine izin verilmez. Ancak yeni bir sürümü etiketledikten sonra bir sonraki adımımız bu etiketle başka bir boru hattı tetiklemekti! Endişelenmeyin, bu tasarımdan kaynaklanıyor - sadece bir sürü koşucuyu yanlışlıkla döndürmeyi önlemek için GitHub'un bir önlemidir. Bu konuda niyetli olmanın birkaç yolu vardır - zaten iki örneğini gösterdim: GitHub Actions Secret ile GitHub Actions Secret kullanımı Kişisel Erişim Tokenini GitHub Eylem Sırrı olarak kullanmak Bir GitHub Uygulaması Oluşturma (teorik olarak - bu seçeneğe ihtiyacım yoktu) Kişisel Erişim Tokenini kullanmak, GitHub ekosisteminde ödeme yapan bir müşteri iseniz uygundur, çünkü kuruluş genelindeki sırlar mevcuttur. Ücretsiz düzeyde, bu bir seçenek değildir, bu yüzden bunun yerine nasıl bir dağıtım anahtarı ayarlayacağınızı göstereceğim. Aslında, bunu yaparak çok basit hale getirdim. Bu harika bir seçenektir, çünkü bu şekilde yapılandırıldığında, herhangi bir insanın bunu bilmesi gerekmez ve aynı komutu yeniden çalıştırarak kolayca döndürülebilir. vnext Kurmak istediğiniz her depolama için Projenin adresinde, bir dağıtım anahtarı ile yayınlamak için... vnext Öncelikle, kullanarak bir token alın Anahtarları yönetmek için izin: gh gh auth refresh -h github.com -s admin:public_key -s admin:ssh_signing_key export GITHUB_TOKEN=$(gh auth token) Ve sonra koş: vnext generate-deploy-key Ne yazık ki, bir Kişisel Erişim Token oluşturmadan Github Eylemleri'nde bu adımı otomatikleştirmenin bir yolunu bulamıyorum, çünkü varsayılan token Sırları değiştiremez. Bu, ücretsiz düzeyde yerine bir Giriş Anahtarı kullanmanın çocuğunu yenebilir, çünkü bunu her repo'da oluşturmanız gerekir. Ne yazık ki, bir Kişisel Erişim Token oluşturmadan Github Eylemleri'nde bu adımı otomatikleştirmenin bir yolunu bulamıyorum, çünkü varsayılan token Sırları değiştiremez. Bu, ücretsiz düzeyde yerine bir Giriş Anahtarı kullanmanın çocuğunu yenebilir, çünkü bunu her repo'da oluşturmanız gerekir. Uygulama Anahtarınız veya Kişisel Erişim Tokeniniz (PAT) yerinde ve sürüm ve etiket iş akışı trunk dalınıza basıyorsa, bir sonraki adım serbest bırakmaktır! Bu projeye göre değişecektir, ancak hepsi önceki adımdan etiketlenen sürüm tarafından tetiklenir. 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 }} Ya da bir Rust projesi olsaydı, belki de böyle bir şey: 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" Ya da bir Dockerfile ve k8'lerin Gitops dağıtımları için kaynak tanımları olan bir uygulama olsaydı, belki de böyle bir şey: 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 Not: Bir dağıtım anahtarı gitops promosyon aşamasında olduğu gibi başka bir repos'a basamaz, bu nedenle bu repository için her yerde bir PAT kullanmayı düşünebilirsiniz. Bu gibi çok sayıda iş yükünüz varsa, her repo'yu ayrı ayrı yapılandırmak yerine, ücretli org'ye yükseltme işe yarayabilir. Not: Bir dağıtım anahtarı gitops promosyon aşamasında olduğu gibi başka bir repos'a basamaz, bu nedenle bu repository için her yerde bir PAT kullanmayı düşünebilirsiniz. Bu gibi çok sayıda iş yükünüz varsa, her repo'yu ayrı ayrı yapılandırmak yerine, ücretli org'ye yükseltme işe yarayabilir. Genel olarak, her sürüm, bu benzer modüllerin bazı parçalarının bir kombinasyonudur, ancak belirli araçları veya diller için aynı şeyleri yaparlar. Normalde, kuruluşlar oluşturdukları uygulamalar ve hizmetler arasında en azından aynı desenleri takip etmeye çalışırlar ve böylece iş akışlarını paylaşılan modüler parçalara bölmek, geliştiricilerin bu paylaşılan iş akış çağrılarının tadını bu tür her projeye kopyalamalarını ve takmalarını sağlar. Changelogs ile Düzenli Yayınlar Belki de bir bakış açısıyla gördüğünüz gibi, Versiyon adımında bayrak. bunun üzerine dönmek istedim, çünkü bu olgun bir yayın sürecinin önemli bir parçasıdır. changelog, projenizin diğer geliştiricilere nasıl değiştiğini iletebileceğinizdir. with.changelog Bumping versiyonları ile birlikte, Aynı zamanda bu changelog'u oluşturmak için komite mesajlarını kullanır ve bu komiteyi sürüm etiketiyle ve sürüm baskınlarıyla birlikte komiteye atanan CHANGELOG.md adında bir dosyaya kaydeder. vnext Yukarıda paylaştığım bu yayın iş akışlarında gizlenmiş olan bu dosya, GitHub Yayınının vücudu olarak kullanılır. Proje Kendisi : vnext Bu sürüm bir düzeltme sürümüydü, çünkü bağımlılık sürümünü bastırma biçiminde bir düzeltme ve diğer bir dizi görev içerdi. Bu notlar daha sonra diğer araçlarda, örneğin , bağımlılıklarınızı güncel tutmak için PR'leri yapan bir araç. Yenileme Pull Requests'i birleştirirken, GitHub'un Squash ve Merge özelliğini kullanmayı seviyorum, böylece changelog'da kullanılacak güzel bir son komite mesajı başlığı ve vücudu yazma şansım olur. Örneğin : Örnekte gösterildiği gibi, komut vücudu olarak tam boyutlu Markdown'u koyabilirsiniz. Release Notes'te uygun şekilde gösterilecektir! Sonuç Versiyonlama ve çıkışın en seksi konu olmadığını biliyorum; oldukça sıkıcı - ya da daha doğrusu, olması gerekir! Ama her zaman öyle değil, bu yüzden yaratıyorum. Ve bir yığın Şimdi, çoğu projeyi çok hızlı bir şekilde kolayca yükleyebilirim! vnext Paylaşılan iş akışları Umarım sizin için de faydalı olur! Lütfen bana bildirin veriyorsanız ve bazı paylaşılan iş akışları bir deneyin! GitHub'da bazı yıldızları ve bunları yararlı bulursanız paylaşmayı takdir ederim! vnext
