Açık Kaynak Donanımı için Sürüm Kontrolü: 10 Adım

2024 Yazar: John Day | [email protected]. Son düzenleme: 2024-01-30 13:20

Brainbow'daki ekibin çok sayıda elektronik projesi var ve biz de elektronik tasarım iş akışımızı yönetmek için sürüm kontrolünü kullanma sürecimizi paylaşmak istedik. Bu iş akışı, basit 2 katmanlı panolardan karmaşık 10 katmanlı devlere kadar büyük ve küçük projeler için kullanılmıştır ve açık kaynaklı araçlara dayanmaktadır. Umarım, diğerleri iş akışımızı kendileri için benimseyebilir ve kendi projeleri için sürüm kontrolünün avantajlarından yararlanabilir. Ancak sürüm kontrolü bir elektronik projesine ne gibi faydalar sağlayabilir?

Adım 1: Elektronik Cihazlarınızı Neden Versiyon Kontrol Etmelisiniz?

Sürüm Kontrolü (aka kaynak kontrolü veya revizyon kontrolü), yazılım mühendisliğinde iyi anlaşılan ve yaygın olarak benimsenen bir kavramdır. Kaynak kontrolünün arkasındaki fikir, bir programın veya uygulamanın kaynak kodunda yapılan değişiklikleri sistematik olarak izlemektir. Değişiklikler uygulamayı bozarsa, kaynak kod dosyalarını geçmişten bilinen bir çalışma durumuna geri döndürebilirsiniz. Uygulamada, kaynak kontrol sistemleri, bir dosya koleksiyonunun (genellikle bir bilgisayar programı, web sitesi vb. için kaynak kod dosyaları) geçmişini izlemenize ve bu dosyalardaki değişiklikleri görselleştirmenize ve yönetmenize izin verir.

Bir projedeki değişikliklerin geçmişini takip etmek, elektronik projeleri için faydalı görünüyor; devre şemasında bir hata yaparsanız veya PCB yerleşiminde yanlış bileşen ayak izini kullanırsanız, bir projenin çeşitli revizyonlarında hangi hataların yapıldığını ve hangi düzeltmelerin yapıldığını takip etmek güzel olurdu. Diğer yapımcıların bu tarihi görmeleri ve çeşitli değişikliklerin bağlamını ve motivasyonlarını anlamaları da faydalı olacaktır.

2. Adım: Araçlar: KiCad ve Git

Bu projede iki ana araç kullanıyoruz: versiyon kontrol sistemi (VCS) ve elektronik tasarım otomasyon programı (EDA veya ECAD).

Dışarıda BİRÇOK sürüm kontrol sistemi var, ancak dağıtılmış VCS Git'i kullanıyoruz. Bunu çeşitli nedenlerle kullanıyoruz, ancak kilit nokta, açık kaynaklı (kontrol edin!), kullanımı kolay (kontrol edin!) ve açık kaynaklı yazılım için fiili standart VCS (kontrol edin!) olmasıdır. ECAD programımızın kullandığı dosyalardaki değişiklikleri izlemek için Git'i VCS olarak kullanacağız. Bu Eğitilebilirlik, Git'e aşinalık gerektirmez, ancak komut satırını kullanmanın genel rahatlığı olduğu varsayılır. Gerektiğinde hem Git hem de komut satırı kullanımı için faydalı kaynaklara bağlantı vermeye çalışacağım.

Çoğu kaynak kontrol sistemi, metin tabanlı dosyalar için özellikle iyi çalışır, bu nedenle metin dosyalarını kullanan bir ECAD programı harika olurdu. CERN'deki araştırmacılar tarafından desteklenen açık kaynaklı "Çapraz Platform ve Açık Kaynak Elektronik Tasarım Otomasyon Paketi" KiCad'e girin. KiCad ayrıca açık kaynaklıdır (kontrol edin!), kullanımı kolaydır (bazıları bu konuda benimle aynı fikirde olmasa da) ve gelişmiş elektronik tasarım çalışmaları için oldukça yeteneklidir.

Adım 3: Kurulum

Bu programları yüklemek için, aşağıda bağlantısı verilen çeşitli indirme sitelerindeki talimatları izleyin.

• KiCad çapraz platformdur (ve baş döndürücü bir şekilde; indirme sayfaları desteklenen 13 işletim sistemini listeler ve bunlardan hiçbiri size uymuyorsa bir kaynak kodu indirmesi sunar). Gecelik geliştirme derlemesini değil, kicad-birleşik varsayılan yüklemesini kullanın. Kitaplık kurulumuyla ilgili gelişmiş isteğe bağlı ayrıntılar için Adım 4'e bakın.
• Git ayrıca çapraz platformdur. Windows kullanıyorsanız, daha kullanışlı, tam özellikli bir deneyim için etkileyici Git for Windows projesini öneririm.

Bu sitelerin her ikisinde de bulunan kurulum belgeleri, burada sunabileceğim herhangi bir açıklamadan daha eksiksiz olacaktır. Her iki program da indirilip kurulduktan sonra, Brainbow'un proje şablonunu Github depomuzdan kopyalayabilirsiniz. git klon komutu, `git klon {src dizini} {hedef dizin}` yapısını alır; projemiz için `git klonu https://github.com/builtbybrainbow/kicad-starter.git {target directory}` kullanın.

Bir git deposunu klonlamak, kopyalamanın özel bir şeklidir; bir projeyi klonladığınızda, depoya dahil edilen tüm dosyaların yanı sıra projenin Git tarafından izlenen tüm geçmişinin bir kopyasını alırsınız. Depomuzu klonlayarak, Git'i KiCad ile kullanma önerilerimizle önceden yapılandırılmış bir proje dizini elde edersiniz. Adım 6'da proje yapısı hakkında daha fazla bilgi vereceğiz veya çalışmaya başlamak için can atıyorsanız Adım 7'ye geçebilirsiniz.

Birkaç hızlı temizlik görevi - klonladığınız Github projesinin bağlantısını kaldırmak için `git remote rm Origin` komutunu çalıştırın. Ayrıca, yazar parametresini adınız ve e-postanızla değiştirerek `git commit --amend --author="John Doe "` komutunu çalıştırın. Bu, son taahhüdü değiştirir (bu durumda aynı zamanda ilk taahhüttür) ve yazarı Brainbow yerine size değiştirir.

Adım 4: Kurulum Notu: KiCad Kitaplıkları

KiCad'in kütüphane yapısı hakkında kısa bir not. KiCad, çok çeşitli elektrikli bileşenler için geliştirici ekibi tarafından sağlanan bir dizi kitaplık sağlar. Üç ana kütüphane vardır:

• Şematik Semboller: Bir devre şematik çiziminde elektronik bileşenleri temsil etmek için kullanılan sembollerdir.
• PCB Ayak İzleri: Devreyi bir PCB üzerinde düzenlerken kullanılacak gerçek ayak izini (bakır pedler, serigrafi metni vb.) temsil eden 2D çizimler.
• 3B Modeller: Elektronik bileşenlerin 3B modelleri.

Bu kütüphaneler, yeni kurduğunuz KiCad program paketi ile birlikte indirilir. KiCad'i daha fazla çaba harcamadan kullanabilirsiniz. Bununla birlikte, "uzman kullanıcılar" için, kitaplıkların kaynak dosyaları Github'daki bir git deposunda depolanır ve bu, kitaplık depolarını kendi makinelerine klonlamak için en son değişikliklerden haberdar olmak isteyen kullanıcılara izin verir. Kitaplıkları git ile izlemenin bir takım avantajları vardır - kitaplıklarınızı ne zaman güncellemek istediğinizi seçebilirsiniz ve güncellemelerin tüm kitaplık dosyalarını yeniden indirmek yerine yalnızca değişiklikleri dosyalara dahil etmesi gerekir. Ancak, unutulması kolay olabilecek kütüphaneleri güncellemekten siz sorumlusunuz.

Kütüphaneleri klonlamak isterseniz, bu site KiCad'in sunduğu çeşitli Github depolarının ayrıntılarını verir. Git, kütüphaneleri bilgisayarınıza klonlayın (örn: `git clone https://github.com/KiCad/kicad-symbols.git`), ardından KiCad'i açın, menü çubuğu "Tercihler" öğesini seçin ve "Yolları Yapılandır… ". Bu, KiCad'e içindeki her bir kitaplığı aramak için dizin yolunu söylemenizi sağlar. Bu ortam değişkenleri, KiCad kurulumuyla kurulan kitaplıkların yolunu varsayılan olarak belirler; Gerekirse varsayılan kitaplıklara geri dönebilmek için bu değerleri not aldım. KICAD_SYMBOL_DIR yolu klonlanmış kicad-symbols kitaplığınıza, KISYSMOD klonlanmış kicad-footprints kitaplığına ve KISYS3DMOD klonlanmış kicad-packages3d kitaplığına işaret etmelidir.

Kütüphaneleri güncellemek istediğinizde, kütüphane deposunda Git'e kütüphane deposunun yerel kopyası ile Github "uzak" deposu arasındaki farkları kontrol etmesini ve otomatik olarak güncellemesini söyleyen basit bir `git pull` komutunu çalıştırabilirsiniz. değişiklikleri dahil etmek için yerel kopya.

Adım 5: Git Temelleri

Git, kapsamlı ve çok yönlü bir programdır ve tüm kitaplarda uzmanlaşmaya adanmıştır. Ancak, iş akışımızda Git'i nasıl kullandığımızı anlamanıza yardımcı olacak birkaç basit kavram vardır.

Git, bir dizi aşama kullanarak dosyalardaki değişiklikleri izler. Normal değişiklikler çalışma dizininde gerçekleşir. Bir dizi dosyada yaptığınız değişikliklerden memnun kaldığınızda, değiştirdiğiniz dosyaları hazırlama alanına eklersiniz. Planladığınız tüm değişiklikleri yaptıktan ve Git'te izlenmesini istediğiniz tüm dosyaları hazırladıktan sonra, bu değişiklikleri depoya uygularsınız. Taahhütler, esasen, belirli bir zamanda bir depodaki dosyaların durumunun anlık görüntüleridir. Git, dosyalardaki değişiklikleri izlediği ve bu değişiklikleri kayıtlarda sakladığından, herhangi bir noktada bir projeyi önceki herhangi bir taahhütte bulunduğu duruma geri döndürebilirsiniz.

Dallanma ve uzaktan kumanda gibi daha karmaşık konular vardır, ancak kaynak denetiminin avantajlarından yararlanmak için bunları kullanmamıza gerek yoktur. Tek ihtiyacımız olan, bir dizi taahhütle KiCad tasarım dosyalarımızdaki değişiklikleri izlemek.

Adım 6: KiCad Proje Yapısı

Daha önce klonladığınız KiCad-Starter projesinin yapısına daha yakından bakalım. Kolay düzenleme için bir dizi alt dizine ayrılmıştır:

• Devre: Bu klasör, gerçek KiCad proje dosyalarını (şematik, PCB, vb.) içerir. Bu klasörü yeniden adlandırmıyorum, ancak içindeki tüm dosyaları projenin adıyla yeniden adlandırıyorum (Circuit.pro => ArduinoMini.pro).

  • Circuit.pro: KiCad proje dosyası
  • Circuit.sch: KiCad şematik dosyası.
  • Circuit.kicad_pcb: KiCad PCB yerleşim dosyası.
• Dokümantasyon: Bu klasör proje ile ilgili dokümantasyonu saklamak içindir. Gelecekte bu alanı geliştirmek için planlarımız var, ancak şimdilik basit bir BENİOKU dosyası içeriyor. Gelecekte gözden geçirmeniz için projeyle ilgili notları saklamak için kullanın.
• Fabrikasyon: Bu klasör, çoğu fab evinin devre kartınızı üretmek için kullanacağı gerber dosyalarını depolayacağınız yerdir. Ayrıca, üretim ve montaj için gerekli olabilecek ürün reçetesi dosyalarını ve diğer belgeleri saklamak için de kullanıyoruz.
• Kitaplıklar: Bu klasör projeye özel kitaplık dosyalarını depolamak içindir (bunu birkaç adımda ele alacağız).

Ayrıca birkaç başka dosya da fark etmiş olabilirsiniz (özellikle dizini `ls -a` yaparsanız)..git dizini, Git'in sihrini yaptığı yerdir ve havuzun geçmişini depolar..gitignore dosyası, Git'e hangi dosyaları yoksayması ve kaynak denetiminde saklamaması gerektiğini söylemek için kullanılır. Bunlar çoğunlukla KiCad'in oluşturduğu yedekleme dosyaları veya ağ listeleri gibi birkaç farklı "oluşturulmuş" dosyadır, bunlar şematik dosya olan kaynaktan oluşturuldukları için kaynak kontrolünde saklanmamalıdır.

Bu proje yapısı sadece bir başlangıç noktasıdır. İhtiyaçlarınıza göre uyarlamalı ve gerekirse bölümler eklemelisiniz. Bazı projelerde, proje için 3B baskı muhafazaları için modelleri depoladığımız bir yazılım klasörü veya muhafaza klasörü ekledik.

7. Adım: KiCad Projeleri için Git'i Kullanma

Sonunda projelerinizi izlemek için Git'i nasıl kullanacağınızı görmeye hazırız. Bu Eğitilebilirlik, size KiCad'i nasıl kullanacağınızı öğretmeyi amaçlamamaktadır (gerçi gelecekte talep olursa bir tane yapabilirim), bu nedenle iş akışının nasıl çalıştığını size göstermek için bazı önemsiz örnekler üzerinden geçeceğiz. Bu fikirlerin gerçek bir projeye nasıl uyarlanacağını anlamak kolay olmalıdır.

kicad-starter dizinini açın, ardından işleme geçmişini görüntülemek için `git log` komutunu çalıştırın. Burada bir taahhüt olmalı, deponun Brainbow tarafından başlatılması. `git status` komutunu çalıştırmak, deponuzdaki dosyaların durumunu (izlenmeyen, değiştirilen, silinen, aşamalı) size söyleyecektir.

Şu anda, deponuzda herhangi bir değişiklik yapmamalısınız. Bir değişiklik yapalım. KiCad projesini açın ve şemaya bir direnç ekleyin, ardından kaydedin. Şimdi `git status` çalıştırıldığında, şematik dosyayı değiştirdiğinizi, ancak bu değişiklikleri henüz taahhüt için hazırlamadığınızı göstermelidir. Direnci eklediğinizde KiCad'in tam olarak ne yaptığını merak ediyorsanız, değiştirilmiş dosya `git diff Circuit/Circuit.sch` üzerinde diff komutunu çalıştırabilirsiniz. Bu, dosyanın çalışma dizinindeki geçerli sürümü ile dosyanın son işlemdeki durumu arasındaki değişiklikleri vurgulayacaktır.

Şimdi bir değişiklik yaptığımıza göre, bu değişikliği proje geçmişimize işlemeyi deneyelim. Değişiklikleri çalışma dizinimizden hazırlama alanına taşımamız gerekiyor. Bu aslında dosyaları dosya sistemindeki taşımaz, ancak kavramsal olarak Git'e belirli bir dosya için planladığınız tüm değişiklikleri yaptığınızı ve bu değişiklikleri uygulamaya hazır olduğunuzu bildirmenin bir yoludur. Yararlı bir şekilde Git, bir sonraki eylem için `git status` komutunu çalıştırdığınızda bazı ipuçları sağlar. 'Taahhüt için hazırlanmayan değişiklikler:' altındaki `(nelerin taahhüt edileceğini güncellemek için "git add …" kullanın)` mesajına dikkat edin. Git, değişiklikleri hazırlama alanına nasıl taşıyacağınızı anlatıyor. Değişiklikleri aşamalandırmak için `git add Circuit/Circuit.sch` komutunu çalıştırın, ardından ne olduğunu görmek için `git status` komutunu çalıştırın. Şimdi yapılacak değişikliklerin altında şematik dosyayı görüyoruz. Bu değişiklikleri henüz yapmak istemiyorsanız, Git yararlı bir şekilde başka bir ipucu sunar: `(unstage'i kaldırmak için "git reset HEAD …" kullanın)`. Bu değişiklikleri yapmak istiyoruz, bu yüzden `git commit -m "Şemaya direnç eklendi"` komutunu çalıştırıyoruz. Bu, sağlanan mesajla değişiklikleri taahhüt eder. Git log'u çalıştırmak, bu taahhüdü proje taahhüt geçmişinde gösterecektir.

Taahhütler hakkında birkaç ipucu daha.

1. Her tasarrufta taahhüt vermeyin. Değişikliklerinizin bir şekilde katılaştığı bir noktaya ulaştığınızı hissettiğinizde taahhütte bulunun. Her bileşen eklemesinden sonra değil, bir şematik bitirdikten sonra taahhüt ederim. Ayrıca çok nadiren taahhütte bulunmak istemezsiniz, çünkü 3 hafta sonra yaptığınız değişiklikleri neden yaptığınızı hatırlamak zor olabilir. Ne zaman taahhütte bulunacağınızı bulmak biraz sanattır, ancak Git'i daha fazla kullandıkça daha rahat hale gelirsiniz.
2. Yalnızca kaynağı depolayın (çoğunlukla). Buna proje, şema ve düzen dosyaları ile projeye özel kitaplıklar dahildir. Bu aynı zamanda dokümantasyon dosyalarını da içerebilir. Türetilmiş nesneleri depolarken dikkatli olun, çünkü bunlar orijinal kaynakla kolayca senkronize olmaktan çıkabilir ve bu daha sonra baş ağrısına neden olur. Malzeme Listesi ve gerber dosyalarının senkronizasyonu özellikle kolay bir şekilde bozulur, bu nedenle bunlardan kaçınılması daha iyidir (her ne kadar Adım 9'da daha ayrıntılı rehberlik ele alınsa da).
3. Taahhüt mesajları çok faydalıdır, ancak iyi yapılandırılmış taahhüt mesajları çok değerlidir. Bu mükemmel makale, açık, özlü, kullanışlı taahhüt mesajları yazmak için bazı yönergeler sağlar. Bunu yapmak, yeni başlayanlar için karmaşık olabilecek bir komut satırı metin düzenleyicisi kullanmayı gerektirebilir (-m mesaj seçeneği olmadan `git commit` bir metin düzenleyici açar). Çoğu insan için Nano editörünü öneririm. StackOverflow'un düzenleyicinizi değiştirme konusunda iyi bir açıklaması var

8. Adım: Gelişmiş: Elektronik için Semantik Sürüm Oluşturma

Maceracı ruhlar için, aşağıdaki ipuçları, saatlerce süren KiCad geliştirmesinden derlenen ileri düzey fikirlerdir. Küçük projelerde özellikle kullanışlı değiller, ancak projeleriniz karmaşıklaştıkça sizi gerçekten gönül yarasından kurtarabilirler.

Yazılımda Anlamsal Sürüm Oluşturma (semver) kavramı vardır. Semver, "Major. Minor. Patch" modelini izleyerek yazılım sürümlerini "sürüm numarasına" göre tanımlamak için ortak bir adlandırma metodolojisi tanımlar. Semver'in özelliklerini alıntılamak için sürüm numarasını aşağıdaki değişiklik kategorilerine göre ilerletirsiniz.

1. Uyumsuz API değişiklikleri yaptığınızda MAJOR sürümü,
2. MINOR sürümü, geriye dönük uyumlu bir şekilde işlevsellik eklediğinizde,
3. Geriye dönük uyumlu hata düzeltmeleri yaptığınızda PATCH sürümü.

Brainbow'da, donanım projelerinin ihtiyaçlarına uyacak şekilde uyarlanmış kendi semver versiyonumuzu kullanıyoruz. Spesifikasyonumuz aynı "Major. Minor. Patch" modelini takip ediyor, ancak hangi değişikliklerin hangi kategoriye girdiğine dair tanımlarımız açıkça farklı.

1. MAJOR sürümü: devrenin temel işlevinde önemli değişiklikler için kullanılır (örn: işlemciyi ATmegaa'dan ESP8266'ya değiştirmek).
2. KÜÇÜK sürüm: devre çalışmasını etkileyebilecek bileşen takasları için kullanılır (örneğin: farklı bir komut setine sahip olabilecek pin uyumlu parça ile SPI flaş takası) veya bazı küçük ek özelliklerin eklenmesi (örneğin: ek sıcaklık sensörü eklendi).
3. YAMA sürümü: devre çalışmasını değiştirmeyecek küçük hata düzeltmeleri için kullanılır (ör. serigrafi ayarı, küçük iz yerleşimi ayarı, 0603 kapasitörden 0805'e kadar basit bileşen takasları).

Donanım semverinde, sürüm numarası yalnızca üretimde güncellenir (tıpkı yazılımda olduğu gibi, sürüm numaraları yalnızca sürümlerle değişir, her birey bir projeye katılmaz). Sonuç olarak, birçok projenin sürüm numaraları düşük. Henüz 4'ten fazla ana sürüm kullanan bir projemiz yok.

İyi tanımlanmış bir adlandırma sistemine geçmenin sağladığı tutarlılık ve anlaşılırlık avantajlarının yanı sıra, ürün yazılımı uyumluluğu ve müşteri memnuniyeti konusunda da avantajlar elde edersiniz. Bellenim, hedeflediği pano sürümü dikkate alınarak yazılabilir ve belirli bir programın belirli bir panoda neden çalışmadığını hata ayıklamak daha kolay olabilir ("doğru, 2.4.1 bellenimi 1.2'de çalışmaz" panolar çünkü bizde yok…"). Müşteri hizmetleri ve sorun giderme, tanımlanmış bir standartla çok daha kolay olduğu için, donanım semverimizden müşteriler de yararlandı.

9. Adım: Gelişmiş: Donanım Anlamsal Sürüm Oluşturma Kullanımı

Donanım semver'i kendi projelerinizde kullanmak için etiketleme adı verilen bir Git özelliği kullanıyoruz. Bir panoyu ilk ürettiğinizde, bu o panonun 1.0.0 sürümüdür. Projenizdeki tüm değişiklikleri yaptığınızdan emin olun, ardından `git tag -a v1.0.0` komutunu çalıştırın. Bu, bu etiket için bir açıklama mesajı yazabilmeniz için bir düzenleyici açacaktır (bir taahhüt mesajına çok benzer). Daha sonra faydalı bilgiler olabilecek imalat (PCB'yi kim yaptı, kartı kim monte etti) ile ilgili detayları ekliyorum.

Yayın etiketi, kesinleştirme geçmişine eklenir ve dosyaların 1.0.0 üretimindeki durumunu gösterir. Bu, sorun giderme için bu noktaya geri dönmeniz gerektiğinde özellikle birkaç revizyonda faydalı olabilir. Belirli bir yayın etiketi olmadan, üretim sırasında hangi taahhüdün en son olduğunu anlamak zor olabilir. 1.0.0 (ve 1.1, 1.1.1, vb.) etiketi, bu belirli kaynak dosyaların belirli bir üretim çalışmasında kullanılanlar olduğunu belirtmenize olanak tanır.

Gerberler üzerine bir not. Bazı muhteşem evler, panonuzu yapmak için gerber dosyaları gerektirir ve bunları KiCad ile oluşturabilirsiniz. Bunlar, kaynak.kicad_pcb dosyasından oluşturulan türetilmiş nesnelerdir ve normalde türetilmiş dosyaların sürüm kontrolünü yapmayız. Brainbow'da bizler, bir sürümü etiketlediğimiz zamanlar DIŞINDA gerberleri sürüm kontrolünde saklamayız. İnşa etmeye hazır olduğumuzda, gerber dosyalarını oluşturuyoruz, bunları Fabrication klasöründe saklıyoruz ve taahhüt edip etiketliyoruz. Ardından gerberleri kaldırıp silme işlemini gerçekleştiriyoruz. Bu ilk başta biraz kafa karıştırıcı görünebilir, ancak normal taahhütlerin yalnızca kaynak dosyaları depolamasını sağlar ve etiketli sürümler ayrıca panoları üretmek için kullanılan dosyaları tam olarak depolar. Bunun, üretim hatalarının haftalar sonra izlenmesinde oldukça yararlı olduğu kanıtlanmıştır.

Adım 10: Sonraki Adımlar

Umarım bu giriş size kendi elektronik projelerinizde sürüm kontrolünü kullanmaya başlamanız için yeterince şey öğretmiştir. Projeler veya özellik dalları arasında paylaşılan kitaplıklar için sürüm kontrolü gibi daha gelişmiş konulardan bazılarına ulaşamadık. Yine de, sürüm kontrolü sebzelerinizi yemek gibidir: Almanız gerektiğini düşündüğünüz şeyi alamayabilirsiniz, ancak yaptığınız her şey önemlidir.

Brainbow, iş akışımızın daha gelişmiş özelliklerinden bazıları için daha ayrıntılı bir kılavuz üzerinde çalışıyor. Önümüzdeki aylarda yayınlamayı umuyoruz. Bizi burada Instructables'ta takip edin ve ne zaman okuyabileceğinizi size bildireceğimizden emin olabilirsiniz.

Okuduğunuz için teşekkürler ve ne yaptığınızı görmek için sabırsızlanıyoruz!