GitHub Eylemleriyle Python için Sürekli Entegrasyon ve Dağıtım
Yazılım oluşturmak, kutlanmaya değer bir başarıdır. Ancak yazılım asla statik değildir. Hataların düzeltilmesi gerekiyor, özelliklerin eklenmesi gerekiyor ve güvenlik düzenli güncellemeler gerektiriyor. Çevik metodolojilerin hakim olduğu günümüz ortamında, sağlam DevOps sistemleri, gelişen bir kod tabanını yönetmek için çok önemlidir. GitHub Actions'ın parladığı yer burasıdır ve Python geliştiricilerine iş akışlarını otomatikleştirme ve projelerinin değişime sorunsuz bir şekilde uyum sağlamasını sağlama olanağı tanır.
GitHub Eylemleri için Python, geliştiricilere iş akışlarını verimli bir şekilde otomatikleştirmelerini sağlar. Bu, ekiplerin sürekli değişime uyum sağlarken yazılım kalitesini korumasını sağlar.
Sürekli Entegrasyon ve Sürekli Dağıtım (CI/CD) Sistemler, iyi test edilmiş, yüksek kaliteli yazılımlar üretmeye ve dağıtımın kolaylaştırılmasına yardımcı olur. GitHub Eylemleri, CI/CD'yi herkes için erişilebilir hale getirerek doğrudan deponuzda iş akışlarının otomasyonuna ve özelleştirilmesine izin verir. Bu ücretsiz hizmet, geliştiricilerin yazılım geliştirme süreçlerini verimli bir şekilde yürütmelerini sağlayarak verimliliği ve kod güvenilirliğini geliştirmelerini sağlar.
Bu eğitimde şunları nasıl yapacağınızı öğreneceksiniz:
- GitHub Eylemleri'ni ve iş akışlarını kullanın
- Bir Python Projesinin lircing, test ve dağıtımını otomatikleştirin
- Güvenli Kimlik Bilgileri Otomasyon için kullanılır
- Güvenlik ve bağımlılık güncellemelerini otomatikleştirin
Bu öğretici, bir CI/CD boru hattı oluşturacağınız bir başlangıç noktası olarak mevcut bir kod tabanı olan Real Python okuyucu kullanacaktır. GitHub'daki gerçek Python okuyucu kodunu takip etmek için çatallayabilirsiniz. Forking sırasında
Bu eğitimden en iyi şekilde yararlanmak için pip
, Python paketleri oluşturma ve Git konusunda bilgi sahibi olmanız ve YAML sözdizimine biraz aşina olmanız gerekir.
GitHub Eylemlerine geçmeden önce bir adım geri çekilip CI/CD'nin yararları hakkında bilgi edinmek faydalı olabilir. Bu, GitHub Actions'ın çözebileceği sorun türlerini anlamanıza yardımcı olacaktır.
CI/CD'nin Avantajlarını Ortaya Çıkarma
Genellikle CI/CD olarak bilinen Sürekli Entegrasyon (CI) ve Sürekli Dağıtım (CD), modern yazılım geliştirmedeki temel uygulamalardır. Bu uygulamalar, kod değişikliklerinin entegrasyonunu, testlerin yürütülmesini ve uygulamaların konuşlandırılmasını otomatikleştirir. Bu, ekiplerin ve açık kaynak katılımcılarının kod değişikliklerini daha sık, güvenilir ve yapılandırılmış bir şekilde sunmalarına yardımcı olur.
Ayrıca, açık kaynaklı Python paketleri yayınlarken CI/CD, kod kalitesini standartlaştırırken paketinize yapılan tüm çekme isteklerinin (PR'ler) ve katkıların projenin ihtiyaçlarını karşılamasını sağlayacaktır.
Not: Çekme isteğinin ne olduğu ve nasıl oluşturulacağı hakkında daha fazla bilgi edinmek için GitHub'un resmi belgelerini okuyabilirsiniz.
Daha küçük kod değişikliklerine sahip daha sık dağıtımlar , daha büyük, daha karmaşık sürümlerle ortaya çıkabilecek istenmeyen kırılma değişiklikleri riskini azaltın. Örneğin, geliştiriciler aynı lirasyon araçlarını ve kurallarını kullanarak tüm kodları biçimlendirebilmelerine rağmen, kodun testleri geçmezse ilke PRS'nin birleştirilmesini otomatik olarak engelleyebilir.
Sonraki bölümde GitHub İş Akışlarının GitHub'da barındırılan bir depoda CI/CD uygulamanıza nasıl yardımcı olabileceğini öğreneceksiniz.
Github iş akışlarını keşfetmek
GitHub İş Akışları, GitHub Eylemlerinin güçlü bir özelliğidir. Depolarınız için özel otomasyon iş akışları tanımlamanıza olanak tanır. Kodunuzu oluşturmak, test etmek veya dağıtmak istiyorsanız GitHub İş Akışları, depo ister genel ister özel olsun, GitHub'daki herhangi bir projenin ücretsiz olarak kullanabileceği esnek ve özelleştirilebilir bir çözüm sunar.
Çok sayıda CI/CD sağlayıcısı olmasına rağmen GitHub Actions, geniş ekosistemi, esnekliği ve düşük veya sıfır maliyeti nedeniyle GitHub'daki açık kaynaklı projeler arasında varsayılan haline geldi.
Bir iş akışı dosyasının anatomisi
İş akışı dosyaları, bir iş akışının başarılı bir şekilde çalışması için yapılması gereken önceden tanımlanmış bir yapıya sahip YAML dosyaları bildirilir. YAML iş akışı dosyalarınız, projenizin kök dizinindeki bir .github/workflows/
klasöründe saklanır ve tanımlanır.
İş akışı klasörünüzde, her biri belirli bir görevi gerçekleştirecek birden fazla iş akışı dosyası bulunabilir. Bu iş akışı dosyalarına istediğiniz adı verebilirsiniz. Ancak basitlik ve okunabilirlik adına, bunları başardıkları görevlere göre adlandırmak yaygın bir uygulamadır; örneğin test.yml
.
Her dosyada gerekli olan birkaç öğe vardır, ancak çok daha fazlası isteğe bağlıdır. GitHub Eylemleri belgeleri kapsamlı ve iyi yazılmış olduğundan, bu eğitimi okumayı bitirdikten sonra mutlaka kontrol edin.
Bir iş akışı dosyasının büyük kısmını oluşturan üç ana parça vardır: tetikleyiciler , iş ve adımlar . Bunları bir sonraki bölümlerde ele alacaksınız.
İş Akışı Tetikleyicileri
Tetikleyici, bir iş akışının çalıştırılmasına neden olan bir olaydır. Pek çok tetikleyici türü vardır. En yaygın olanları aşağıdaki durumlarda meydana gelenlerdir:
- Çekme isteği
- Varsayılan şubeye kaydetildi
- Taahhüt etiketli
- Manuel tetikleyici
- Başka bir iş akışı tarafından istek
- Yeni Sorun Açılıyor
Ayrıca, belirli bir dal veya dosya kümesiyle sınırlandırarak tetikleyicileri daha da kısıtlamak isteyebilirsiniz. İşte ana dala herhangi bir itme iş akışı çalıştıran basit bir tetik örneği:
on:
push:
branches:
- main
Bu eğitimde ele alınmayan tetikleyiciler hakkında ayrıntılı bilgi için resmi belgelere göz atabilirsiniz.
Artık olayların iş akışlarını nasıl tetiklediğini bildiğinize göre, bir iş akışı dosyasının bir sonraki bileşenini keşfetme zamanı: Jobs.
İş Akışı İşleri
Her iş akışının, iş akışının et ve patateslerin kabı olan tek bir iş
bölümü vardır. Bir iş akışı, çalıştıracağı bir veya daha fazla iş içerebilir ve her iş bir veya daha fazla adım içerebilir.
Aşağıda, bu bölümün herhangi bir adım olmadan nasıl görüneceğine dair bir örnek verilmiştir:
# ...
jobs:
my_first_job:
name: My first job
my_second_job:
name: My second job
Bir iş oluşturduğunuzda yapmanız gereken ilk şey, işinizi yürütmek için kullanmak istediğiniz koşucuyu tanımlamaktır. runner
, işlerinizi sizin için yürüten, GitHub tarafından barındırılan bir sanal makinedir (VM). GitHub, CI/CD'niz için herhangi bir altyapının bakımı konusunda endişelenmenize gerek kalmaması için VM'nin tedarikini ve provizyonunu kaldıracaktır.
Birden fazla desteklenen işletim sistemi mevcuttur. Github barındıran koşucuların tam listesini belgelerde bulabilirsiniz.
Not: Ücretsiz ve sınırsız sürümler ihtiyaçlarınızı karşılamıyorsa, kendi kendine barındırılan koşucular da bir seçenektir. Bu eğitim, kendi kendine barındırılan koşucuları kapsamaz, ancak kendi kendine barındırılan koşucuları kullanma hakkında ayrıntılı bilgiyi resmi belgelerde bulabilirsiniz.
Bir koşucuyu tanımlamak, tek bir YAML satırı kadar az alır:
# ...
jobs:
my_first_job:
name: My first job
runs-on: ubuntu-latest
# ...
my_second_job:
name: My second job
runs-on: windows-latest
# ...
Yukarıdaki örnekte, my_first_job
bir Ubuntu VM'sinde çalışacak ve my_second_job
bir Windows VM'sinde çalışacaktır. Bu durumda her ikisi de -latest
son ekini kullanır, ancak desteklenen bir sürüm olduğu sürece işletim sisteminin tam sürümünü de belirtebilirsiniz (örneğin, ubuntu-20.24
). versiyon.
İş Akışı Adımları
Adımlar bir işin ana kısmıdır. Muhtemelen tahmin ettiğiniz gibi adımlar, iş akışını yürütürken gerçekleştirilmesi gereken eylemleri bildirir. Bu, Python'u yükleme, testleri çalıştırma, kodunuzu yazma veya başka bir GitHub eylemi kullanma gibi görevleri içerebilir.
Tıpkı Python kodunuz gibi, ortak ve tekrarlanabilir görevler de ayrı iş akışlarına ayrılabilir ve yeniden kullanılabilir. Bu, bir Python kitaplığını içe aktarırken yaptığınız gibi, diğer kişilerin GitHub Eylemlerini kendi iş akışlarınızda kullanabileceğiniz ve kullanmanız gerektiği anlamına gelir; böylece bu işlevselliği yeniden uygularken zamandan tasarruf edersiniz.
Bir sonraki bölümde diğer GitHub Eylemlerini nasıl kullanabileceğinizi ve bunları nasıl bulacağınızı göreceksiniz.
Python için Github Eylemlerini Kullanma
İş akışları GitHub eylemlerinin bir parçası olsa da, iş akışları GitHub eylemlerini de içerebilir. Başka bir deyişle, iş akışınızda diğer kişilerin veya kuruluşların eylemlerini kullanabilirsiniz. Aslında, yaygın bir uygulamadır ve iş akışı dosyalarınızda mevcut Github eylemlerini kullanmaya çok teşvik edilir. Bu uygulama, önceden oluşturulmuş işlevlerden yararlanarak size zaman ve çaba kazandırır.
Bunu başarmanız gereken belirli bir göreviniz varsa, bunu yapmak için muhtemelen bir GitHub eylemi vardır. İleride dalacağınız GitHub pazarında ilgili GitHub eylemlerini bulabilirsiniz.
Github pazarını keşfetmek
GitHub Marketplace, insanların kendi iş akışlarında kullanabileceği tüm eylemlerin çevrimiçi bir deposudur. GitHub, üçüncü taraf satıcılar ve bireyler bu GitHub Eylemlerini oluşturur ve sürdürür. Herkes kendi eylemini oluşturmak ve bunu piyasada barındırmak için GitHub Eylem şablonunu kullanabilir.
Bu, akla gelebilecek hemen hemen her tür görev otomasyonu için geniş bir GitHub Eylemleri dizisinin mevcut olmasına yol açtı. GitHub Marketplace'teki tüm eylemler açık kaynaktır ve kullanımı ücretsizdir.
Bir sonraki bölümde her Python projesi için kullanacağınız iki GitHub Eylemine bakacaksınız.
İş akışlarındaki eylemler dahil
Oluşturduğunuz her Python tabanlı iş akışının, mevcut deponuzu yalnızca iş akışı ortamına kontrol etmekle kalmayıp aynı zamanda Python'u kurup kurması gerekir. Neyse ki, Github'ın her iki göreve de yardımcı olacak resmi Github eylemleri var:
# ...
jobs:
my_first_job:
name: My first job
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.13"
- run: python -m pip install -r requirements.txt
Yukarıdaki örnekte, adımlar
'daki ilk adımın resmi ödeme
eylemini kullanmak olduğunu görebilirsiniz. Bu eylem, kodu deponuzdan geçerli GitHub çalışma alanına teslim ederek iş akışınızın ona erişmesine olanak tanır. checkout
'un ardından gelen @4
, eylemin hangi sürümünün kullanılacağını belirten bir sürüm belirticidir. Şu an itibariyle en son sürüm v4.2.2'dir, dolayısıyla en son ana sürümü belirtmek için bu sözdizimini kullanarak ona başvurabilirsiniz.
Bu örneğin ikinci adımı ortamda Python'u kurar. Yine bu örnekte, devam eden destek ve geliştirme nedeniyle bunu yapmak için resmi GitHub Action kullanılmaktadır. Hepsi olmasa da çoğu eylemin, adıma ekleyebileceğiniz ekstra yapılandırmaları vardır.
Kurulum Python Eylem Belgeleri, yapılandırmaların tam listesini içerir. Şimdilik, Python'u iş akışı ortamınıza yüklemeniz gereken minimum, hangi Python sürümünü yüklemek istediğinizi bildirmektir.
Örneğin son adımında run
komutunu kullanacaksınız. Bu komut, adım için hangi çalıştırıcıyı kullandığınıza bağlı olarak herhangi bir bash
veya powershell
komutunu çalıştırmanıza olanak tanır. Bu durumda projenin bağımlılıklarını gereksinimler dosyasından yüklüyorsunuz.
Umarım GitHub Eylemlerinin ne kadar güçlü olabileceğini görebilirsiniz. Çok az kod ve çabayla Python projenizi oluşturmaya, test etmeye ve dağıtmaya hazır bir ortam oluşturmanın tekrarlanabilir bir yoluna sahip olursunuz.
Artık bir iş akışı dosyasının yapısına ve bir proje için ilk iş akışınızı nasıl oluşturabileceğinize ilişkin temel bilgilere sahipsiniz. Bir sonraki bölümde gerçek dünyadan bir örnekle tam da bunu yapacaksınız.
İlk İş Akışınızı Oluşturma
Mevcut bir gerçek dünya projesi olan Real Python Reader'a CI/CD ekleme adımlarını gözden geçirmenin zamanı geldi. Bu paketi test etmek ve dağıtmak için iş akışları eklemeden önce ilk olarak linting ile başlamalısınız.
Linter, kodunuzu analiz eden ve hatalar, stilistik sorunlar ve şüpheli yapılar arayan bir araçtır. LINTRE, sorunları ele almanıza ve başkalarıyla paylaşmadan önce kod kalitenizi artırmanıza olanak tanır. CI/CD'nizi LIDRE ile başlatarak, paketi PYPI'ye dağıtmadan önce kodunuzun temiz ve okunabilir olduğundan emin olacaksınız.
Not: LinTRed sizin için yeni bir kavramsa, modern bir Python Linter olan Ruff hakkında okuyarak daha fazla bilgi edinebilirsiniz.
Bu iş akışında Python kodunu lintlemek için Ruff'ı kullanacaksınız. Ancak henüz yapmadıysanız, önce tüm şubeler dahil olmak üzere depoyu çatallayın ve ardından klonlayın. kullanıcı adınızı GitHub kullanıcı adınızla değiştirdiğinizden emin olun:
$ git clone git@github.com:your-username/reader.git
$ cd reader/
$ git checkout github-actions-tutorial
$ mkdir -p .github/workflows/
Çatallı deponuzu klonladıktan ve mevcut çalışma dizininizi değiştirdikten sonra,
Doğru şubeye başarılı bir şekilde geçiş yaptıktan sonra iş akışlarınızı saklayacak bir klasör oluşturun. Bu klasöre workflows/
adı verilmeli ve .github/
klasörünün bir alt dizini olmalıdır.
Not: Mevcut GitHub Eylemleri olan bir depoyu çatalladığınızda, çatallanmış deponuzun Eylemler sekmesini tıkladıktan sonra bunları etkinleştirmenizi isteyen bir istem görebilirsiniz. Bu bir güvenlik özelliğidir. Eylemleri etkinleştirmek istediğinizi onayladığınızda bu eğitimin geri kalanını takip ederken herhangi bir sorun yaşamayacaksınız.
Şimdi, tetikleyicilerinizi tanımlayacağınız, çevreyi ayarlayacağınız ve Ruff yükleyeceğiniz ilk iş akışınızı oluşturmaya hazırsınız. Başlamak için tetikleyicilerinizi
name: Lint Python Code
on:
pull_request:
branches:
- master
push:
branches:
- master
workflow_dispatch:
Gerekli olmasa da, her bir iş akışınıza net, insan tarafından okunabilir bir isim vermek için en iyi uygulama olarak kabul edilir. Bu ad, GitHub deposundaki Eylemler sekmesinin sol sütununda görünecektir. Önceki iş akışlarınız boyunca mevcut iş akışlarını ve filtrelemenizi tanımlamanıza yardımcı olur:
Adı tanımladıktan sonra odağınızı bu iş akışına ilişkin tetikleyicilere kaydırabilirsiniz. Yukarıdaki kodda iş akışını başlatabilecek tanımlanmış üç farklı tetikleyici vardır:
- Çekme İsteği Açma
- Yerel taahhütleri zorlamak
- İş akışını manuel olarak göndermek
İlk ikisi, master
dalındaki herhangi bir push veya çekme isteği olayında iş akışını tetikleyecektir. Bu, koddaki herhangi bir değişikliğin, doğrudan master
dalına birleştirmek için bir çekme isteği kullanacağı anlamına gelir. depo.
Not: Bu iş akışı, başka bir dal üzerinde çalışırken master
dalındaki olaylar tarafından tetiklenir. İşlemin GitHub'a ittikten hemen sonra yürürlüğe girdiğini görmek isterseniz, iş akışı tarafından izlenen dallar listesine github-Actions-tutorial
eklemeyi düşünün.
Son tetikleyicinin ne yaptığı belli değil. Belgelere göre, süresi dolmuş bir API anahtarı gibi kod değişiklikleriyle ilgisi olmayan nedenlerden dolayı başarısız olan bir iş akışını yeniden çalıştırmak için yaygın olarak kullanılır. Ancak workflow_dispatch
tetikleyicisi yalnızca iş akışı dosyası varsayılan dalda olduğunda çalışır.
Tetikleyiciler tanımlandıktan sonra iş akışı dosyasını oluşturmanın bir sonraki adımına geçmenin zamanı geldi: işleri tanımlamak ve ortamı yapılandırmak:
name: Lint Python Code
on:
pull_request:
branches:
- master
push:
branches:
- master
workflow_dispatch:
jobs:
lint: # The name of the job
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.13"
cache: "pip"
Bu kodun çoğu önceki örneklerden tanıdık gelmelidir, ancak birkaç küçük fark var. İlk olarak, ne yaptığını açıklamak için ubuntu-latest
olarak tanımladınız.
Ardından, setup-python
eyleminin artık yüklü paketlerin PIP bağımlılıklarını önbelleğe almak için yapılandırıldığını fark edeceksiniz. Bu, bir paketin sürümleri aynı ise gelecekteki çalışmalarda iş akışınızı hızlandırmaya yardımcı olur. Onları Pypi'den çekmek yerine önbelleğe alınmış versiyonları kullanacak.
Not: İş akışlarınızda önbelleklemeyi nasıl kullanabileceğiniz hakkında daha fazla bilgi edinmek için GitHub belgelerini kontrol edebilirsiniz.
Artık iş akışınızın tanımlı bir tetikleyicisi ve çalıştırıcısı olduğuna ve kod ödemeniz ve Python kurulu olduğuna göre, Ruff'u yükleyip kodu lintlemek için çalıştırmanın zamanı geldi. Bunu lint
işinize iki adım daha ekleyerek yapabilirsiniz:
name: Lint Python Code
on:
pull_request:
branches:
- master
push:
branches:
- master
workflow_dispatch:
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.13"
cache: "pip"
- name: Install dependencies
run: |
python -m pip install --upgrade pip
python -m pip install ruff
- name: Run Ruff
run: ruff check --output-format=github
tiftik
işinin son iki adımında, daha önce gördüğünüz run
komutunu kullanırsınız. YAML sözdiziminin bir parçası olarak, ikinci satırda bir boru ( | |
) sembolü fark edeceksiniz. Bu çok satırlı bir dizeyi gösterir. run
komutu, aşağıdaki satırları ayrı komutlar olarak yorumlar ve bunları sırayla yürütür.
Ruff'u yükledikten sonra iş akışı, tüy bırakma hatalarını aramak için Ruff'un çalıştırılmasıyla son olarak tamamlanır. Bu komutla, --output-format
etiketiyle çıktının bir github
iş akışında çalışacak şekilde optimize edilmesini istediğinizi belirtebilirsiniz.
Not: Ruff kullanıyorsanız ve varsayılanın dışında kendi yapılandırmalarınız varsa, bu son iki adımı Ruff'un kendi GitHub Eylemiyle değiştirebilirsiniz.
Tebrikler! İlk iş akışınızı tamamladınız. Bu iş akışı deponuza bağlı ve itildikten sonra GitHub, tetik koşulu karşılandığında bu natür iş akışını otomatik olarak çalıştırır. Bu iş akışını GitHub web sitesinde herhangi bir zamanda manuel olarak da tetikleyebilirsiniz. Bunu yapmak için, deponuzdaki Eylemler sekmesine gidin, sol taraftan istenen iş akışını seçin ve ardından iş akışını çalıştırmayı tıklayın:
Artık kemerinizin altında bir iş akışınız olduğuna ve iş akışlarının nasıl çalıştığını anladığınıza göre, gerçek python okuyucusunda test paketini çalıştıran bir tane oluşturma zamanı.
Otomatik Test İş Akışı Oluşturma
Artık ilk GitHub iş akışınızla ayaklarınızı ıslattığınıza göre, bu paket için tüm iş akışlarının tartışmasız en önemlisine bakmanın zamanı geldi: otomatik test.
Gerçek Python Okuyucusu, test çerçevesi olarak pytest
'i kullanır. GitHub Eylemleri hakkında öğrendiklerinizi dikkate alarak, astarlama iş akışını bir test iş akışına dönüştürmek için nasıl düzenleyebileceğinizi bile görebilirsiniz. Sonuçta pytest
'i çalıştırmaya hazırlanmak için aynı adımları izleyeceksiniz. Bir yazılım paketini test ederken onu Python'un tüm desteklenen sürümlerinde test etmeniz gerektiğini unutmamak önemlidir.
Ancak önce tüm GitHub iş akışlarında olduğu gibi test iş akışına yönelik tetikleyicileri bildirmeniz gerekir:
name: Run Tests
on:
push:
branches:
- master
pull_request:
branches:
- master
workflow_call:
workflow_dispatch:
Yukarıdakilerin çoğu önceki linting iş akışıyla aynıdır ancak tek bir farkla; artık yeni bir tetikleyici var: workflow_call
. workflow_dispatch
'e benzer şekilde, workflow_call
da diğer iş akışlarının bu iş akışını tetiklemesine olanak tanıyan önceden tanımlanmış bir tetikleyicidir.
Bu, gelecekte testlerin de geçmesini gerektiren bir iş akışınız varsa, kodu tekrarlamak yerine yeni iş akışından bu test iş akışını kullanmasını isteyebileceğiniz anlamına gelir. İş akışı daha sonra adımlarından biri olarak bu test iş akışını tetikleyecek ve işin diğer adımlarına geçmeden önce geçmesini sağlayacaktır. Böylece daha fazla tekrara gerek kalmaz ve iş akışlarınızı daha kısa ve hedefe yönelik tutabilirsiniz.
Bu iş akışı yöntemini test.yml
iş akışınızda kullanmayacak olsanız da, bunu 'ı kullanarak iş akışı dosyanızdaki diğer Github eylemlerini çağırırsanız aynı şekilde başaracaksınız.
anahtar kelime kullanır:
# Github-username/repo/path/to/workflow@version
- uses: realpython/reader/.github/workflows/test.yml@master
Burada, yol benzeri bir dizeyi uses
'a ileterek iş akışını yeniden kullanabileceğinizi görebilirsiniz. GitHub kullanıcı adı ve depo adı ile başlamalı ve ardından kullanmak istediğiniz iş akışı dosyasının yolu gelmelidir. @master
, yeni iş akışına master
dalındaki test iş akışının sürümünü kullanmak istediğinizi bildirir. Artık GitHub Eylemlerinin ne kadar güçlü olabileceğini görebilirsiniz. İş akışlarını yeniden kullanmak GitHub Actions'ın büyük bir avantajıdır.
Artık test iş akışı için tetikleyicileri tanımladığınıza göre şu soruyu sormanın zamanı geldi: Python'un birden fazla sürümünde nasıl test yaparsınız? Bir sonraki bölümde, adımlarınızı nasıl bir kez tanımlayabileceğinizi ve her çalıştırmanın farklı bir Python sürümünde olacak şekilde birden çok kez çalıştırılmasını nasıl sağlayabileceğinizi göreceksiniz.
Python'un birden çok versiyonunda test
LinTRing iş akışında, Ubuntu örneğinde Python 3.13'ü ayarlamak için STEP'lerinizdeki setup-python
eylemini kullandınız:
# ...
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.13"
cache: "pip"
# ...
# ...
Ne yazık ki, stratejisi
matrisidir.
Resmi belgeleri alıntılamak için:
Bir matris stratejisi, değişkenlerin kombinasyonlarına dayanan birden fazla iş çalışması oluşturmak için değişkenleri tek bir iş tanımında kullanmanızı sağlar. Örneğin, kodunuzu bir dilin birden çok sürümünde veya birden çok işletim sisteminde test etmek için bir matris stratejisi kullanabilirsiniz. (Kaynak)
Kısacası,
Bir stratejinin ilan edilmesi nispeten basittir. Adımlarınızı tanımlamadan önce ancak işinizin bir parçası olarak gerekli stratejinizi tanımlayabilirsiniz:
name: Run Tests
on:
push:
branches:
- master
pull_request:
branches:
- master
workflow_call:
workflow_dispatch:
jobs:
testing:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ["3.9", "3.10", "3.11", "3.12", "3.13"]
Gördüğünüz gibi, sürüm numaralarından oluşan bir dizi olan python-version
değişkenini bildiriyorsunuz. Harika, bu ilk bölüm tamamlandı! İkinci kısım, özel bir değişken sözdizimi kullanarak setup-python
eylemine bu sürümleri kullanmak istediğinizi söylemektir:
name: Run Tests
on:
push:
branches:
- master
pull_request:
branches:
- master
workflow_call:
workflow_dispatch:
jobs:
testing:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ["3.9", "3.10", "3.11", "3.12", "3.13"]
steps:
- uses: actions/checkout@v4
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python-version }}
cache: "pip"
İş akışının Python kurulum adımında artık iki değişiklik var. İlki, adıma eklenen name
'dir. Daha önce öğrendiğiniz gibi bu gerekli değildir ancak adımın adında Python sürümüne atıfta bulunarak hangi Python sürümünün başarısız olduğunu belirlemenize yardımcı olacaktır. Bu adımın Python'un beş farklı sürümü için çalışacağı göz önüne alındığında bu faydalıdır.
İkinci değişiklik, sürüm numarasını setup-python
'in bir kısmı, şimdi python- Sürüm
Matrix'te tanımlanmıştır.
GitHub, iş akışlarınızın bir parçası olarak erişebileceğiniz birkaç özel bağlama sahiptir. Matrix bunlardan biri. Matrisi stratejinin bir parçası olarak tanımlayarak, python-sürüm
artık matris bağlamının bir özelliği haline gelmiştir. Bu, matrisin bir parçası olarak tanımlanan herhangi bir değişkene DOT (.
) sözdizimi, örneğin, Matrix.python-Sürüm
ile erişebileceğiniz anlamına gelir.
Bu, Real Python Reader için yapılması gereken bir şey olmasa da, aynı şeyi farklı işletim sistemi sürümleriyle yapabilirsiniz. Örneğin:
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
Daha sonra matrix.os
ile matriste tanımladığınız os
değişkenine erişmek için aynı nokta gösterimini kullanabilirsiniz.
Artık Python'un farklı bir sürümünü kullanarak adımlarınızı bildiren bir şekilde çalıştırmak için bir matrisi nasıl kullanacağınızı bildiğinize göre, test iş akışını tam olarak tamamlamanın zamanı geldi.
Test İş Akışını Sonlandırma
İş akışını tamamlamak için yalnızca birkaç adıma daha ihtiyaç var. Artık Python yüklendiğine göre, iş akışının geliştirici bağımlılıklarını yüklemesi ve ardından son olarak pytest
'i çalıştırması gerekecektir.
Real Python Reader paketi, bağımlılıklarını bildirmek için bir pyproject.toml
yapılandırma dosyası kullanır. Ayrıca pytest
'i içeren isteğe bağlı geliştirici bağımlılıkları da vardır. Bunları, daha önce Ruff'u yüklediğiniz gibi, run
komutunu kullanarak yükleyebilirsiniz:
name: Run Tests
on:
push:
branches:
- master
pull_request:
branches:
- master
workflow_call:
workflow_dispatch:
jobs:
testing:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ["3.9", "3.10", "3.11", "3.12", "3.13"]
steps:
- uses: actions/checkout@v4
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python-version }}
cache: "pip"
- name: Install dependencies
run: |
python -m pip install --upgrade pip
python -m pip install .[dev]
Gerekli bağımlılıkları yüklemek için ihtiyacınız olan tek şey bu adımdır. Geriye kalan tek adım pytest
'i çalıştırmaktır:
name: Run Tests
on:
push:
branches:
- master
pull_request:
branches:
- master
workflow_call:
workflow_dispatch:
jobs:
testing:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ["3.9", "3.10", "3.11", "3.12", "3.13"]
steps:
- uses: actions/checkout@v4
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python-version }}
cache: "pip"
- name: Install dependencies
run: |
python -m pip install --upgrade pip
python -m pip install .[dev]
- name: Run Pytest
run: pytest
Bu noktada, ana cihazda bir PR veya push olayı gerçekleştiğinde tetiklenen hem bir astarlama hem de test iş akışına sahip olursunuz. Daha sonra dikkatinizi CI/CD'nin CD kısmına çevirecek ve bir paketi PyPI'de otomatik olarak nasıl yayınlayabileceğinizi öğreneceksiniz.
Paketinizi otomatik olarak Pypi'ye yayınlamak
Üçüncü iş akışı çoğu insanın minimum CI/CD hattı olarak gördüğü süreci tamamlıyor. Bu üçüncü iş akışı, bir paket oluşturmak ve yayınlamak için tekrarlanabilir ve tutarlı bir yol sağlar. Real Python Reader paketi, daha sonra PyPI'ye dağıtılabilen Python dağıtım dosyalarını oluşturmak için yaygın olarak kullanılan Python build
kitaplığını kullanır.
İş akışları biraz daha karmaşıklaştığında ve birden fazla adım veya işiniz olduğunda, adımları ve akışı yazmanız önerilir. Bu, kullandığınız GitHub eylemlerinin en başından itibaren doğru şekilde yapılandırılması için tüm adımları doğru sırada almanıza yardımcı olacaktır. Bu, yapı iş akışınızdaki potansiyel hatalardan kaçınmanıza yardımcı olarak daha sonra zaman kazandıracaktır.
İşte
- Ortamı kurun Python'u kurarak ve bağımlılıklar oluşturarak
- Paketi oluşturun Çıktı dosyalarını bir
dist/ klasörüne yerleştirerek - dağıtım dosyalarını yayınlayın
- bir github sürümü oluşturun başarıyla yayınlanırsa
Bir sonraki bölümde, listedeki ilk iki öğeyi ele alacak ve iş akışınızın iyi bir bölümünü yazacaksınız.
Paketin Kurulumu ve Oluşturulması
Son iki iş akışında olduğu gibi, ilk adım iş akışı için tetikleyicileri tanımlamaktır. Tipik geliştirici iş akışları etrafında dönen bazı yaygın tetikleyiciler gördünüz, ancak her yeni PR ile otomatik olarak yayınlamak veya ana şubeye itmek gerçek Python okuyucusu için ideal değildir.
Birkaç çekme isteğinden, hata düzeltmesinden veya yeni özellikler ekledikten sonra paketin sürümünü yükseltmek daha mantıklı olur. Sürüm artışından sonra böyle bir sürümü tetiklemenin modern yolu, geliştiricinin en iyi arkadaşı Git'i kullanmaktır.
GIT, yazılımın geliştirilmesinde önemli bir zaman belirtmek için bir taahhüdü etiketlemenizi sağlar. Bu genellikle yeni bir sürüm tanımlamak için tercih edilen bir araçtır. Github eylemleri, etiketleri
anahtar kelime üzerinden tetikleyici olarak git etiketlerini kullanmak için yerleşik desteğe sahiptir:
name: Publish to PyPI
on:
push:
tags:
- "*.*.*"
Burada görebileceğiniz gibi, tetikleyiciler küresel desenleri de destekler. Böylece bir yıldız işareti (*
) bir dizideki herhangi bir karakterle eşleşebilir. Yukarıda özetlenen desen, herhangi bir karakterle ve ardından ondalık bir nokta (.
), başka bir karakter, başka bir ondalık nokta ve son olarak başka bir karakterle eşleşecektir.
Bu, 1.0.0'ın 2.5.60 gibi geçerli bir eşleşme olduğu anlamına gelir. Bu, Real Python Reader tarafından kullanılan anlamsal sürümleme ile eşleşir. İsterseniz v
ile başlamalıdır. Örneğin, v1.0.0 geçerli bir etiket olacaktır.
Bu iş akışını tetiklemek için, sürüm adıyla bir taahhüdü etiketlersiniz:
$ git tag -a "1.0.0" -m "1.0.0"
$ git push --tags
Yeni etiketinizi GitHub'a itmek daha sonra bu iş akışını tetikleyecektir. Ardından, çevreyi kuracak ve bağımlılıkları kuracaksınız:
name: Publish to PyPI
on:
push:
tags:
- "*.*.*"
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.13"
- name: Install dependencies
run: |
python -m pip install --upgrade pip
python -m pip install .[build]
- name: Build package
run: python -m build
Öncelikle yayınlama
işini tanımlayacak ve Python 3.13'ü bir Ubuntu VM'ye yükleyeceksiniz. Bir sonraki adım, Real Python Reader'ın derleme bağımlılıklarını yükler. Son adımda, daha önce kullandığınız run
komutunun aynısını kullanacaksınız, ancak bu sefer Ruff veya pytest
'i çalıştırmak yerine Gerçek Python Okuyucusunu oluşturacaksınız. paket. Varsayılan olarak build
, dağıtım dosyalarını dist
adlı bir klasöre yerleştirir.
Harika! İş akışı planının ilk iki ana bölümünü uyguladınız. PyPI'ye dağıtım yapmadan önce PyPI API belirtecinizi nasıl güvende tutacağınızı bilmelisiniz.
Sırlarınızı güvende tutmak
Daha önce öğrendiğiniz gibi iş akışları matrix
gibi özel bağlamlara erişim sağlar. Tüm iş akışlarının erişebildiği başka bir bağlam da gizli sırlar
bağlamıdır. Hassas verileri depo sırrı olarak depolayarak API anahtarlarını, şifreleri veya diğer kimlik bilgilerini asla yanlışlıkla sızdırmayacağınızdan emin olabilirsiniz. İş akışınız, secrets
bağlamını kullanarak bu hassas kimlik bilgilerine erişebilir.
GitHub web sitesinde deponuza sırlar ekleyebilirsiniz. Bunları ekledikten sonra görüntüleyemez veya düzenleyemezsiniz. Bunları yalnızca yeni bir değerle değiştirebilirsiniz. GitHub web sitesine gizli dizilerin nasıl ekleneceğini görmek için GitHub belgelerini incelemek iyi bir fikirdir. Resmi belgeler, herhangi bir kullanıcı arayüzü değişikliğiyle sürekli olarak güncellenir ve bu da onları bu GitHub özelliğinin nasıl kullanılacağını öğrenmek için en iyi kaynak haline getirir.
Paketinizi Dağıtma
API anahtarınızı GitHub sırrı olarak güvence altına aldıktan sonra ona iş akışından erişebilirsiniz:
name: Publish to PyPI
on:
push:
tags:
- "*.*.*"
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.13"
- name: Install dependencies
run: |
python -m pip install --upgrade pip
python -m pip install .[build]
- name: Build package
run: python -m build
- name: Test publish package
uses: pypa/gh-action-pypi-publish@release/v1
with:
user: __token__
password: ${{ secrets.PYPI_API_TOKEN }}
repository-url: https://test.pypi.org/legacy/
- name: Publish package
uses: pypa/gh-action-pypi-publish@release/v1
with:
user: __token__
password: ${{ secrets.PYPI_API_TOKEN }}
Bu adımda, PyPI'yi yöneten Python Packaging Authority'nin (PyPA) resmi GitHub Action'ını kullanacaksınız. Bu GitHub Eylemi işin çoğunu yapar ve yalnızca PyPI API belirtecinize bir referans gerektirir. Yine varsayılan olarak yüklenecek herhangi bir paketin yeni sürümünü bulmak için dist
klasörünüze bakacaktır.
PYPI'ye kimlik doğrulaması yapmak için geleneksel bir kullanıcı adı ve şifre kullanmak yerine, otomatik sürümler için kapsamlı bir API jetonu kullanmak en iyi uygulamadır.
Bir API jetonu kullandığınızdan ve kullanıcı adı, GitHub eylemine belirteç kimlik doğrulamasının kullanıldığını söylediği için __ jeton __
kullanan kullanıcı adı olmadığından. Tıpkı önceki matris stratejisinde olduğu gibi, Secrets.pypi_API_TOKEN> 'da olduğu gibi gizli bağlama erişmek için DOT gösterimini kullanabilirsiniz.
GitHub'da saklanan sırrın adı, sizin için anlamlı olduğu sürece önemli değildir. GitHub sırrının adı PYPI_API_TOKEN
olduğundan iş akışı içinde bu adı kullanarak ona başvurursunuz.
İş akışının, paketi PyPI'de yayınlamadan önce bir test adımı içerdiğini fark etmiş olabilirsiniz. Bu adım, yayınlama adımıyla neredeyse aynıdır, tek önemli farkla: varsayılan URL'yi geçersiz kılmak ve paketi test.pypi.org'a göndermek için bir repository-url
sağlamanız gerekir.
TestPypi'yi kullanmak, paketinizin doğru bir şekilde oluşturulmasını ve sürümlenmesini sağlamak için mükemmel bir yoldur. Ana PYPI deposuna yayınlanırken sorunlara neden olabilecek olası sorunları tanımlamanıza ve ele almanıza olanak tanır.
Deponun kendi çatalını takip ediyorsanız ve sürümünüzü PYPI'ye itmek istiyorsanız, projenin adını benzersiz bir adla güncellemeniz gerekir. Proje adını güncellemiyorsanız, yüklemeye çalışırken bir HTTP 403 hatası alacaksınız. Bunun nedeni, realpython-reader
paketini PYPI'ye yayınlama izniniz olmamasıdır. Proje adını güncellemek, kendi sürümünüzü yayınlamanıza olanak tanır.
Örnek olarak, kullanıcı adınızı proje adına bir ön ek olarak ekleyebilirsiniz:
[build-system]
requires = ["setuptools>=61.0.0", "wheel"]
build-backend = "setuptools.build_meta"
[project]
name = "username-realpython-reader"
# ...
İş akışının tamamlanması için sadece bir adım daha var - tanıtmak için bir GitHub sürümü yaratmak ve daha sonra sürümü doğrudan paylaşmak. Bunu yapmadan önce GitHub ortam değişkenleri hakkında bilgi edineceksiniz.
Github ortam değişkenlerine erişme
Bir GitHub reposuna sürüm yayınlamak için bir GitHub jetonu gereklidir. Github API'sını daha önce kullandıysanız bunları daha önce kullanmış olabilirsiniz. Kişisel Github jetonlarını iş akışlarında kullanma riski göz önüne alındığında, GitHub varsayılan olarak sır bağlamında salt okunur bir jeton oluşturur. Bu, ihtiyacınız varsa her zaman ona erişebileceğiniz anlamına gelir.
Buna ek olarak, her Github koşucusu varsayılan olarak kullanışlı GitHub CLI içerir. Bu, bir sürüm oluşturmak gibi belirli görevlerin gerçekleştirilmesini çok daha basit hale getirir. GitHub CLI, kullanıcıyı doğrulamanın birçok yolu vardır, bunlardan biri github_token
adlı bir ortam değişkeni ayarlayarak.
Bunun nereye varacağını görebilirsiniz. Sağlanan GitHub belirteci, CLI'ye erişmek ve sonuçta GitHub sürümünü oluşturmanın kusursuz bir yolunu oluşturmak için kullanılabilir. İş akışında bunun nasıl görüneceği aşağıda açıklanmıştır:
name: Publish to PyPI
on:
push:
tags:
- "*.*.*"
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: "3.13"
- name: Install dependencies
run: |
python -m pip install --upgrade pip
python -m pip install .[build]
- name: Build package
run: python -m build
- name: Test publish package
uses: pypa/gh-action-pypi-publish@release/v1
with:
user: __token__
password: ${{ secrets.PYPI_API_TOKEN }}
repository-url: https://test.pypi.org/legacy/
- name: Publish package
uses: pypa/gh-action-pypi-publish@release/v1
with:
user: __token__
password: ${{ secrets.PYPI_API_TOKEN }}
- name: Create GitHub Release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh release create ${{ github.ref_name }} ./dist/* --generate-notes
39. ve 40. satırlarda iş akışının özellikle gizli diziler bağlamından GitHub belirtecini GITHUB_TOKEN
adlı bir ortam değişkenine atadığını göreceksiniz. env
'de ayarlanan tüm anahtar değerler, geçerli adım için ortam değişkenleri olarak ayarlanacaktır. Bu, GitHub CLI'yi (gh
) çalıştırdığınızda, atanmış ortam değişkeni aracılığıyla belirtece erişebileceği anlamına gelir. GitHub CLI, gizli diziler bağlamının kendisine doğrudan erişemez.
GitHub ayrıca github
adı verilen özel bir bağlama erişmenizi sağlar. İş akışı, github
bağlamında ref_name
özelliğine başvuruyor. Bu, GitHub belgelerinde şu şekilde tanımlanır:
İş akışı çalışmasını tetikleyen şubenin veya etiketin kısa ref adı. (Kaynak)
Yani, github.ref_name
, bu durumda git etiketinin adı olan iş akışını tetikleyen öznitelik ile değiştirilecektir.
Yukarıdaki GH
komutu, sürümü tetiklemek,
Eksik ayrıntıları sürüm notlarına eklemek isteyebilirsiniz. Kullanımdan kaldırma bildirimleri gibi ek bilgiler eklemeniz gerekirse, sürümlerin oluşturulduktan sonra düzenlenebileceğini unutmayın.
Tebrikler! Artık otomatikleştirilmiş Linting, Test ve Dağıtım'a sahipsiniz. En son işleminizi etiketleyebilirsiniz; son dağıtım iş akışı başarıyla çalışmalıdır:
Gerçek Python Reader'ın gelecekteki kod tabanı değişikliklerinin sağlam olduğundan ve okunabilir ve tutarlı bir kodu kullanmasını sağlamak için bir CI/CD boru hattına sahip olduğundan, Real Python Reader'a bir iş akışı daha ekleyebilirsiniz. CI/CD kekimizin üst kısmındaki kiraz, tabiri caizse.
Bir sonraki bölümde, Dependabot'u güvenlik ve bağımlılık güncellemelerini otomatikleştirecek şekilde nasıl yapılandıracağınızı öğreneceksiniz.
Güvenlik ve bağımlılık güncellemelerini otomatikleştirme
Tıpkı Python kodu gibi, GitHub iş akışlarınızın korunması ve güncel tutulması gerekir. Ayrıca, gerçek Python okuyucu kodunun dayandığı kütüphaneler her zaman değişiyor ve güncelleniyor, bu nedenle bağımlılıkları korumak ve yönetmek zor.
Projeyi GitHub'da veya sosyal medyada aktif olarak takip etmiyorsanız, bağımlılıklarınız tarafından yayınlanan güvenlik güncellemelerinden haberdar olmak özellikle zor olabilir. Neyse ki GitHub'ın her iki soruna da yardımcı olacak kullanışlı bir aracı var. Dependabot'a girin!
D’inTABOT, size bağımlılıklarınızda yalnızca bir güvenlik açığı bildirmekle kalmayacak, aynı zamanda yapılandırılmışsa, sorunu sizin için güncellemek ve düzeltmek için otomatik olarak bir PR oluşturacak bir otomasyon aracıdır. Tek yapmanız gereken otomatik PR ve birleştirmeyi gözden geçirmektir. Bağımla ilgili olarak, paketinizi güncel ve bilinen güvenlik açıklarından uzak tutmak hızlı ve kolaydır, kodunuzu geliştirmek veya yeni özellikler eklemek için kullanabileceğiniz zaman kazandırır.
Projenizin ihtiyaçlarını karşılayacak şekilde bağımlı olarak yapılandırabilirsiniz. Burada, gerçek Python okuyucu paketi oldukça temel gereksinimlere sahiptir. İki hedef:
- Bir bağımlılık güncellemesi olduğunda bilgilendirilmek için.
- Diğer iş akışlarını güncel tutmaya yardımcı olmak için.
Bu gereksinimler, bağımlıcabot.yml
adlı bir yapılandırma dosyasında tanımlanır. Diğer iş akışlarından farklı olarak, Dosya> .Github
klasörün kendisinde,
Bu dosya yalnızca on iki satır uzunluğunda olduğundan ve artık YAML sözdizimine daha aşina olduğunuzdan, son Dependabot yapılandırmasına göz atabilirsiniz:
---
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
sürüm
özellik dosyanın zorunlu bir parçasıdır. Bu, kullanılacak olan bağımlılığın sürümünü tanımlayacaksınız ve sürüm 2 en sonuncusu. Başka bir zorunlu bölüm güncellemeleri
. Konfigürasyonun büyük kısmı burada. Her güncelleme, hangi DirectorBot'un arama yapması gerektiği ve ne sıklıkta arama yapması gerektiği ile ilgili temel bilgilerle birlikte kontrol etmek için paket ekosistemini tanımlar.
İlk güncelleme için, D’abot, pyproject.toml
gibi ortak dosyaları kontrol edecektir. . Gerçek Python Reader, kök dizininde bir pyproject.toml
dosyasına sahip olduğundan, D’abot'a ileri eğik çizgi ( "/"
) tarafından belirtildiği gibi oraya bakması talimatı verilir.
Bağımlılık güncellemelerinden ne sıklıkla bilgilendirilmek istediğiniz size bağlıdır. Her projenin kendi gereksinimleri olacaktır. Bununla birlikte, YAML'de ilan etmek, kadansı çok fazla bulursanız veya yeterli değilse, hızlı ve basit bir değişiklik olduğu anlamına gelir. Şimdilik Weekly
kullanabilirsiniz.
güncellemeler
listesindeki ikinci öğe github-actions
içindir. Doğru, Dependabot ayrıca daha yeni sürümler için setup-python
gibi depodaki herhangi bir iş akışında kullanılan GitHub Eylemlerini de kontrol edecek! Bu, GitHub Actions'ın en son sürümlerine otomatik olarak ayak uydurmanızı sağlar ve endişelenmeniz gereken bir şey daha azalır.
Not: Dependabot ile kullanabileceğiniz çok daha fazla yapılandırma ayarı vardır; bunlar arasında, bir PR oluşturduğunda GitHub kullanıcılarını incelenmek üzere otomatik olarak etiketleme seçeneği de vardır. Diğer yapılandırma seçenekleri hakkında daha fazla bilgi için resmi GitHub Dokümanlarına bakın.
Bu yapılandırma uygulandığında Dependabot, bağımlılıklarda veya iş akışlarınızda yapabileceğiniz herhangi bir güncelleme olup olmadığını görmek için deponuzu haftada bir kez tarayacak ve kontrol edecektir. Otomatik olarak düzeltme içeren bir PR oluşturacaktır. Dependabot'un bu PR'leri aynı zamanda Dependabot'un değişikliklerinin astarlama ve test kontrollerinizi geçmesini sağlamak için diğer iş akışlarınızı da çalıştıracaktır. Çifte galibiyet!
Sonraki Adımlar
Deponuz büyüdükçe otomatikleştirebileceğiniz, sorun önceliklendirmesi, etiketleme, eski sorun yönetimi, PR'lere inceleyenleri ekleme ve daha fazlası gibi birçok başka görev vardır.
Ayrıca GitHub Actions'ın yalnızca bir CI/CD sağlayıcısı olduğunu unutmayın. Projeniz GitHub'da barındırılıyorsa GitHub Eylemleri işleri sizin için kolaylaştırabilir. Kodunuz başka bir platformdaysa veya alternatifleri denemek istiyorsanız diğer CI/CD sağlayıcılarının kısa bir listesini burada bulabilirsiniz:
- GitLab
- Azure İşlem Hatları
- Circleci
- Travis CI
Zaten bu sağlayıcılardan birini veya listelenmemiş bir tane kullanıyorsanız, lütfen yorumlarda bağırıp deneyimlerinizi paylaşmaktan çekinmeyin.
Çözüm
Artık GitHub eylemlerini kullanarak bir Python projesi için sağlam bir CI/CD boru hattının nasıl uygulanacağını biliyorsunuz. Bu öğreticinin amacı, mevcut bir kod tabanına CI/CD ekleyeceğinizi öğrenmek için olsa da, umarım artık kendi projeleriniz ve paketlerinizle çalışmak ve kendi iş akışlarınızı sıfırdan oluşturmak için yeterince bilirsiniz.
Bu eğiticide şunları nasıl yapacağınızı öğrendiniz:
- GitHub Eylemleri'ni ve iş akışlarını kullanın
- Bir Python Projesinin lircing, test ve dağıtımını otomatikleştirin
- Otomasyon için kullanılan güvenli kimlik bilgileri
- Güvenlik ve bağımlılık güncellemelerini otomatikleştirin
Bu süreçleri otomatikleştirerek projenizin sürdürülebilirliğini ve güvenilirliğini önemli ölçüde artırdınız. Artık minimum manuel müdahaleyle kod kalitesini garantilemek, testleri çalıştırmak ve yeni sürümleri dağıtmak için tutarlı bir yönteme sahipsiniz.
CI/CD'nin yinelenen bir süreç olduğunu unutmayın. Projeniz büyüyüp geliştikçe iş akışlarınızı ayarlamanız veya yenilerini eklemeniz gerekebilir. GitHub Actions'ın esnekliği değişen gereksinimlere kolayca uyum sağlamanıza olanak tanır.
Bu araçlar ve uygulamalar sayesinde Python projelerinizi verimli bir şekilde yönetmek ve ölçeklendirmek için iyi donanıma sahip olursunuz.