Mitchell Hashimoto’un HashiCorp araçları—Terraform ve Vagrant—ekiplere altyapıyı standartlaştırma ve tekrar edilebilir teslimat iş akışları oluşturma konusunda nasıl yardımcı olduğunu öğrenin.
Tekrarlanabilir teslimat sadece kod göndermekle ilgili değildir. Aynı zamanda şu sorulara güvenle cevap verebilme yetisidir: Ne değişecek? Neden değişecek? Ve yarın bunu tekrar yapabilir miyiz? Altyapı elle kurulduğunda—veya geliştirici makineleri zaman içinde farklılaştığında—teslimat bir tahmin oyununa dönüşür: farklı ortamlar, farklı sonuçlar ve bolca “laptop'umda çalışıyor” durumu.
Terraform ve Vagrant, bu öngörülemezliği iki yönden azaltmaya devam ediyor: paylaşılan altyapı ve paylaşılan geliştirme ortamları.
Terraform altyapıyı (bulut kaynakları, ağ, yönetilen servisler ve bazen SaaS yapılandırmaları) kod olarak tanımlar. Konsolda tıklamak yerine ne istediğinizi tanımlarsınız, bir plan gözden geçirme yaparsınız ve değişiklikleri tutarlı şekilde uygularsınız.
Amaç “gösterişli olmak” değil; altyapı değişikliklerini görünür, incelenebilir ve tekrarlanabilir kılmaktır.
Vagrant tutarlı geliştirme ortamları oluşturur. macOS, Windows veya Linux üzerinde, ekiplerin aynı temel kurulumu—OS, paketler ve yapılandırma—çalıştırmasına yardımcı olur.
Günlük olarak sanal makineleri kullanmıyor olsanız bile, Vagrant’in çekirdek fikri önemini korur: geliştiriciler yazılımın gerçek çalışma şekline uyan, bilinen-iyi bir ortamdan başlamalıdır.
Bu, daha az pazarlama deyimi ve daha fazla açıklama isteyen uzman olmayanlar için hazırlanmış pratik bir yürüyüştür. Şunları ele alacağız:
Sonunda, Terraform, Vagrant veya her ikisinin ekibiniz için uygun olup olmadığını ve bunları yeni bir karmaşıklık katmanı oluşturmadan nasıl benimseyeceğinizi değerlendirebileceksiniz.
Mitchell Hashimoto, Vagrant'ı oluşturması ve HashiCorp'u kurmasıyla tanınır. Kalıcı katkı tek bir ürün değil—araçların bir ekibin iş akışını paylaşılabilir, incelenebilir ve tekrarlanabilir bir şeye dönüştürebileceği fikridir.
“Tooling bir köprüdür” denildiğinde, aynı sonucu isteyen ama günlük dillerinde farklı konuşan iki grup arasındaki boşluğu kapatma kastedilir:
Hashimoto'nun bakışı—HashiCorp araçlarında yankı bulan—köprünün herkesin görebileceği bir iş akışı olduğu yönündedir. Talimatları ticket'larla veya sözlü bilgiyle aktarmak yerine ekipler kararları yapılandırma dosyalarına kaydeder, bunları versiyon kontrolüne gönderir ve aynı komutları aynı sırayla çalıştırırlar.
Araç hakem olur: adımları standartlaştırır, neyin değiştiğini kaydeder ve “laptop'umda çalışıyor” tartışmalarını azaltır.
Paylaşılan iş akışları altyapıyı ve ortamları ürün-benzeri bir arabirime dönüştürür:
Bu çerçeve teslimata odaklanmayı sağlar: araçlar yalnızca otomasyon için değil, anlaşma için vardır. Terraform ve Vagrant bu zihniyete uyuyor çünkü istenen durumu açıkça ifade ediyor ve sürümlendirme, gözden geçirme, tekrar çalıştırma gibi uygulamaları teşvik ediyor—bu uygulamalar tek bir kişinin hafızasının ötesine ölçeklenir.
Çoğu teslimat sıkıntısı “kötü koddandır” diye ortaya çıkmaz. Çoğunlukla ortamların uyuşmaması ve kimsenin tam olarak tarif edemediği görünmez, elle yapılan adımlardan kaynaklanır—ta ki bir şey bozulana kadar.
Ekipler genellikle çalışan bir kurulumla başlar ve sonra küçük, makul değişiklikler yaparlar: bir paket yükseltmesi buraya, bir güvenlik duvarı ayarı oraya, bir sunucuda acil bir düzeltme çünkü “acil”. Haftalar sonra geliştirici dizüstü bilgisayarı, staging VM'i ve üretim birbirinden biraz farklı hâle gelir.
Bu farklılıklar yeniden üretmesi zor hatalara dönüşür: testler yerelde geçer ama CI'da başarısız olur; staging olur ama üretim 500 verir; geri alma önceki davranışı geri getirmez çünkü altta yatan sistem değişmiştir.
Ortamlar elle oluşturulduğunda gerçek süreç kabilesel hafızada yaşar: hangi OS paketlerinin kurulacağı, hangi servislerin başlatılacağı, hangi kernel ayarlarının yapılacağı, hangi portların açılacağı—ve hangi sırayla.
Yeni katılanlar “yeterince yakın” bir makine kurmak için günler kaybedebilir. Kıdemli mühendisler temel kurulum soruları için tıkanma noktası olur.
Başarısızlıklar genellikle sıradandır:
.env dosyasına kopyalanır ama üretimde farklı çekilir—deploylar başarısız olur ya da daha kötüsü, gizli bilgiler sızar.Bu sorunlar işe alımın yavaşlaması, teslim sürelerinin uzaması, beklenmedik kesintiler ve acı geri almalar anlamına gelir. Ekipler daha az sık ve daha az güvenle gönderir; zamanlarının büyük kısmını “bu ortam neden farklı” sorusunu teşhis ederek geçirirler, ürünü geliştirmek yerine.
Terraform, altyapıyı dosyalarda tarif ederek konsolda rastgele ayar hatırlamaya dayanmaktan kurtarır. Bu dosyalar genellikle Git'te bulunur, böylece değişiklikler görünür, incelenebilir ve tekrarlanabilir olur.
Terraform yapılandırmasını bir altyapı “yap-reçetesi” gibi düşünün: ağlar, veritabanları, yük dengeleyiciler, DNS kayıtları ve izinler. Yaptığınızı sonradan belgelemek yerine, ne olması gerektiğini tanımlarsınız.
Bu tanım önemlidir çünkü nettir. Bir ekip arkadaşı aynı ortama ihtiyaç duyarsa aynı yapılandırmayı kullanabilir. Bir olayı takiben bir ortamı yeniden oluşturmanız gerekirse, bunu aynı kaynaktan yapabilirsiniz.
Terraform, arzu edilen durum fikri etrafında çalışır: ne istediğinizi beyan edersiniz ve Terraform oraya ulaşmak için hangi değişikliklerin gerektiğini hesaplar.
Tipik döngü şöyle işler:
Bu “önizle sonra uygula” yaklaşımı ekipler için Terraform'u parlattığı yerdir: kod gözden geçirme, onaylar ve öngörülebilir dağıtımlar desteklenir.
“IaC tamamen otomatik anlamına gelir.” Zorunlu değil. Özellikle üretim değişiklikleri için insan kontrol noktalarını korumak genellikle doğrudur. IaC, insanları süreçten çıkarmak değil tekrarlanabilirlik ve netlik sağlamaktır.
“Tek bir araç tüm altyapı ve teslim sorunlarını çözer.” Terraform, altyapıyı sağlama ve değiştirmede iyidir, ama iyi mimariyi, izlemeyi veya operasyonel disiplini ikame etmez. Ayrıca her şeyi eşit iyi yönetmez; bazı kaynaklar başka sistemlerle daha iyi idare edilir—bu yüzden geniş bir iş akışının parçası olarak kullanmak en iyisidir.
Vagrant’ın görevi basittir: her geliştiriciye tek bir yapılandırma dosyasından aynı çalışan ortamı isteğe bağlı olarak sağlamaktır.
Merkezde Vagrantfile vardır; burada temel imajı (bir “box”), CPU/RAM, ağ, paylaşılan klasörler ve makinenin nasıl yapılandırılacağı tanımlanır.
Kod olduğu için ortam incelenebilir, sürümlenebilir ve paylaşılması kolaydır. Yeni bir ekip üyesi repoyu klonlayıp tek bir komut çalıştırarak doğru OS sürümü, paketler, servisler ve varsayılanları içeren öngörülebilir bir kurulum elde edebilir.
Konteynerler bir uygulamayı ve bağımlılıklarını paketlemek için harikadır, ama host kernel'ı paylaşırlar. Bu, ağ, dosya sistemi davranışı, arka plan servisleri veya OS düzeyinde araçlar gibi farklılıklara hâlâ yol açabilir—özellikle üretim tam bir Linux VM'ine daha yakınsa.
Vagrant tipik olarak VirtualBox, VMware veya Hyper-V gibi sağlayıcılar aracılığıyla sanal makineler kullanır. Bir VM kendi kernel'ı ve init sistemi ile gerçek bir bilgisayar gibi davranır. Bu, konteynerlerin iyi modellemediği şeyleri test etmek gerektiğinde daha uygun bir eşleşme sağlar: sistem servisleri, kernel ayarları, iptables kuralları, çoklu NIC ağı veya “sadece Ubuntu 22.04'te bozuluyor” türü sorunlar.
Bu bir yarış değil: birçok ekip uygulama paketleme için konteynerleri, gerçekçi ve tam sistem geliştirme ve test için Vagrant'ı kullanır.
Kısacası, Vagrant sanallaştırma için değil—ekibinizin güvenebileceği paylaşılan bir iş akışı yapmak içindir.
Terraform ve Vagrant farklı sorunları çözer, ama birlikte “laptop'ımda çalışıyor”dan “herkes için güvenilir şekilde çalışıyor”a giden net bir yol yaratırlar. Köprü, uygulamanın varsayımlarını tutarlı tutmaktır; hedef ortam değişse bile uygulamanın beklentileri aynı kalır.
Vagrant ön kapıdır. Her geliştiriciye tekrarlanabilir bir yerel ortam verir—aynı OS, aynı paketler, aynı servis sürümleri—böylece uygulama bilinen bir başlangıç noktasından başlar.
Terraform paylaşılan temeldir. Takımların birlikte güvendiği altyapıyı tanımlar: ağlar, veritabanları, compute, DNS, yük dengeleyiciler ve erişim kuralları. Bu tanım test ve üretim için gerçek bir kaynak olur.
Bağlantı basittir: Vagrant uygulamayı gerçekliğe benzeyen bir ortamda inşa edip doğrulamanıza yardımcı olur; Terraform ise gerçeği (test/üretim) tutarlı, incelenebilir şekilde sağlar ve değiştirir.
Her hedef için aynı aracı kullanmazsınız—aynı sözleşmeyi kullanırsınız.
DATABASE_URL ve REDIS_URL gibi ortam değişkenlerini bekler.Vagrant bu sözleşmeyi yerelde uygular. Terraform bunu paylaşılan ortamlarda uygular. Uygulama aynı kalır; sadece “nerede” değişir.
Dizüstü (Vagrant): Bir geliştirici vagrant up çalıştırır, uygulama çalıştırma zamanı ile birlikte Postgres ve Redis içeren bir VM elde eder. Hızla yineleme yapar ve “yerelde çalışıyor” hatalarını erken yakalar.
Test (Terraform): Bir pull request, test veritabanı ve uygulama örnekleri sağlamak için Terraform'u günceller. Ekip gerçek altyapı kısıtlarına karşı davranışı doğrular.
Üretim (Terraform): Aynı Terraform desenleri üretim ayarlarıyla uygulanır—daha büyük kapasite, daha sıkı erişim, daha yüksek kullanılabilirlik—kurulumu yeniden icat etmeden.
İşte köprü: yerel uyumluluk, paylaşılan altyapıya beslenir; teslimat kontrollü bir ilerlemeye dönüşür, her aşamada yeniden icat edilmez.
İyi bir Terraform/Vagrant iş akışı komutları ezberlemekten çok, değişikliklerin kolayca gözden geçirilebilir, tekrar edilebilir ve geri alınabilir hâle gelmesini sağlamaktır.
Hedef: bir geliştirici yerelde başlayıp, uygulama değişikliğiyle birlikte altyapı değişikliğini önerip, bu değişikliği sürpriz olmadan ortamlar boyunca terfi ettirebilsin.
Birçok ekip uygulama ve altyapıyı aynı repoda tutar, böylece teslim hikâyesi tutarlı kalır:
/app — uygulama kodu, testler, build varlıkları/infra/modules — yeniden kullanılabilir Terraform modülleri (ağ, veritabanı, uygulama servisi)/infra/envs/dev, /infra/envs/test, /infra/envs/prod — ince ortam katmanları/vagrant — Vagrantfile ve gerçek bağımlılıkları yansıtacak provizyon betikleriÖnemli desen “ince env'ler, kalın modüller”: ortamlar çoğunlukla girdileri (boyutlar, adetler, DNS adları) seçer; ortak modüller gerçek kaynak tanımlarını barındırır.
Kısa ömürlü feature branchleri ve pull request tabanlı bir trunk yaklaşımı iyi işler.
İncelemede iki artefakt isteyin:
terraform fmt, validate çalıştırır ve PR için bir terraform plan çıktısı üretir.Gözden geçirenler “Ne değişecek?” ve “Güvenli mi?” sorularına yerelde yeniden üretmeye gerek kalmadan yanıt verebilmelidir.
Aynı modül setini dev → test → prod arasında terfi ettirin; farkları açık ve küçük tutun:
Ortamlara göre tüm klasörleri kopyalamaktan kaçının. Kaynak tanımlarını yeniden yazmak yerine değişkenlerle terfi etmeyi tercih edin.
Bir uygulama değişikliği yeni altyapı gerektiriyorsa (ör. bir kuyruk veya yeni konfigürasyon), bunları aynı PR'da gönderin ki tek bir birim olarak incelensin.
Altyapı birçok servis tarafından paylaşılıyorsa, modülleri ürün gibi ele alın: versiyonlayın (tag/sürüm) ve girdiler/çıktılar olarak bir sözleşme dokümante edin. Böyle ekipler bilinçli yükseltmeler yapar, yanlışlıkla “en son olan”a sapmazlar.
Terraform'un süper gücü sadece altyapı oluşturmak değil—zamanla güvenli şekilde değiştirebilmesidir. Bunu yapmak için, oluşturduklarını ve var olduğunu düşündüğü şeyleri hatırlayan bir belleğe ihtiyacı vardır.
Terraform state, yapılandırmanız ile gerçek dünya kaynakları arasındaki eşlemeyi tutan bir dosya veya depodur: hangi veritabanı örneğinin hangi kaynağa ait olduğu, ID'leri ve en son uygulanan ayarlar gibi.
State olmadan Terraform her şeyi yeniden tarayarak neyin var olduğunu tahmin etmeye çalışırdı; bu yavaş, güvenilmez ve bazen imkânsız olurdu. State ile Terraform neyin ekleneceğini, değiştirileceğini veya yok edileceğini hesaplayabilir.
State bazen kaynak tanımlayıcıları—ve bazen gizli değere yakın veriler—içerebildiği için bir kimlik bilgisi gibi ele alınmalıdır. Birisi onu okursa veya değiştirirse Terraform'un neyi değiştireceğini etkileyebilir.
Drift, altyapı Terraform dışında değiştirildiğinde ortaya çıkar: bir konsol düzenlemesi, gece acil bir düzeltme veya otomatik bir süreç ayarı değiştirdiğinde.
Drift gelecekteki planları sürprizli hale getirir: Terraform manuel değişikliği geri almaya çalışabilir veya varsayımlar eşleşmediği için başarısız olabilir.
Ekipler genellikle state'i uzak tutar (bir dizüstü yerine) ki herkes aynı gerçek kaynağa karşı plan ve apply yapsın. İyi bir uzak kurulum ayrıca şunları sağlar:
Güvenli teslimat çoğunlukla sıkıcıdır: tek bir state, kontrollü erişim ve değişikliklerin gözden geçirilebilir planlardan geçmesi.
Terraform, aynı blokları kopyalamayı bırakıp ortak desenleri modüller halinde paketlemeye başladığınızda gerçek gücünü gösterir. Bir modül girdiler (VPC CIDR aralığı veya instance boyutu gibi) alır ve çıktılar (subnet ID'leri, veritabanı uç noktası) üretir. Getiri: daha az çoğaltma, daha az “snowflake” kurulum ve ekiplerin bilinen-iyi bir yapı taşıyla daha hızlı başlaması.
Modül yoksa altyapı kodu copy/paste varyantlarına dönüşür: biri güvenlik grubu kurallarını değiştirir, diğeri şifreleme ayarını unutur, başkası farklı provider sürümü sabitler.
Modül bir kararı kodlamak ve zamanla iyileştirmek için tek bir yer sağlar. Gözden geçirmeler de kolaylaşır: her seferinde 200 satır ağ kodunu yeniden denetlemek yerine küçük bir modül arayüzünü inceleyebilirsiniz; modül evrilince merkezi olarak güncellenir.
İyi modüller çözümün şeklini standardize eder, anlamlı farklılıklara yer bırakır.
Örnek modülleştirmeye değer desenler:
Her olasılığı kodlamayın. Bir modülün kullanılabilir olması için 40 girdiye ihtiyacı varsa muhtemelen çok fazla işlevi tek başına çözmeye çalışıyordur. Makul varsayılanları ve az sayıda politika kararı (şifreleme açık, gerekli etiketler, onaylanmış instance aileleri) tercih edin; kaçış yolları nadir ve açık olsun.
Herkes biraz farklı sürümler yayınlarsa modüller bir labirente dönüşebilir (“vpc-basic”, “vpc-basic2”, “vpc-new”). Çoğalma genellikle net bir sahiplik, sürüm disiplini ve yeni modül yaratma ile mevcut modülü geliştirme arasındaki rehberlik eksikliğinden doğar.
Pratik koruyucular:
İyi yapıldığında, modüller Terraform'u paylaşılan bir iş akışına çevirir: ekipler “doğru yol” paketlendiği, keşfedilebilir ve tekrarlanabilir olduğu için daha hızlı hareket eder.
Terraform ve Vagrant ortamları yeniden üretilebilir kılar—ama hataları da çoğaltır. Bir repoda sızan tek bir token dizüstü bilgisayarlardan CI işlerine ve üretim değişikliklerine kadar yayılabilir. Birkaç basit alışkanlık çoğu yaygın hatayı önler.
“Ne inşa edileceği” (konfigürasyon) ile “nasıl kimlik doğrulanacağı” (sırlar) ayrı konular olarak ele alınmalıdır.
Altyapı tanımları, Vagrantfile'lar ve modül girdileri kaynakları ve ayarları tanımlamalıdır—şifreleri, API anahtarlarını veya özel sertifikaları değil. Bunun yerine sırrı çalışma zamanında güvenilir bir secret store'dan (ör. Vault, bulut sağlayıcısının secret manager'ı veya sıkı kontrol edilen bir CI gizli deposu) çekin. Bu, kodun gözden geçirilebilir ve hassas değerlerin denetlenebilir kalmasını sağlar.
Her aktöre sadece ihtiyacı olan izinleri verin:
terraform plan çalıştırabilen bir geliştirici otomatik olarak üretimi apply etme iznine sahip olmamalıdır. Onay ve yürütme ayrı kişilere verilebilir.Kod içine kimlik bilgisi gömmekten, yerel dotfile'ların kopyalanmasından veya paylaşılan “takım anahtarları” kullanmaktan kaçının. Paylaşılan sırlar hesabı ortadan kaldırır.
Bu koruyucular teslimatı yavaşlatmaz—bir şeyler ters gittiğinde etki alanını küçültür.
CI/CD, Terraform'un “tek kişinin çalıştırdığı bir şey” olmaktan çıkarak bir ekip iş akışı hâline geldiği yerdir: her değişiklik görünür, incelenir ve aynı şekilde uygulanır.
Pratik bir temel üç adımdan oluşur ve pull request ile dağıtım onaylarına bağlanır:
terraform fmt -check ve terraform validate çalıştırarak bariz hataları erken yakalayın.terraform plan üretin ve çıktıyı PR için yayınlayın (artifact veya yorum olarak). Gözden geçirenler “Ne değişecek? Nerede? Neden?” sorularına cevap verebilmeli.terraform apply çalıştırın.# Example (GitHub Actions-style) outline
# - fmt/validate on PR
# - plan on PR
# - apply on manual approval
Anahtar ayrım: PR'lar delil (plan) üretir; onaylar değişikliği yetkilendirir (apply).
Vagrant CI'nin yerini tutmaz ama yerel testlemeyi CI düzeyine yaklaştırır. Bir hata raporu “laptop'ımda çalışıyor” dediğinde, paylaşılan Vagrantfile herkesin aynı OS, paket ve servis sürümünü ayağa kaldırıp hatayı yeniden üretmesini sağlar.
Bu özellikle faydalıdır:
Eğer ekip teslimat iş akışlarını standartlaştırıyorsa, Terraform ve Vagrant tutarlı uygulama iskeletleri ve tekrar edilebilir sürüm adımlarıyla birlikte en iyi sonucu verir.
Koder.ai burada bir hızlandırıcı olabilir: ekipler sohbetten çalışan bir web/backend/mobile başlangıç oluşturabilir, sonra kaynak kodunu dışa aktarabilir ve bunu yukarıda tanımlanan Git-temelli iş akışına (Terraform modülleri ve CI plan/apply kapıları dahil) takabilirler. Bu, Terraform veya Vagrant'ın yerine geçmez; ilk commit'e kadar geçen süreyi azaltırken altyapı ve ortam uygulamalarınızı açık ve incelenebilir tutar.
Terraform altyapı değişikliklerini açık, incelenebilir ve tekrar edilebilir hâle getirir. Konsoldaki tıklamalara veya çalıştırma notlarına güvenmek yerine yapılandırmayı versiyon kontrolüne gönderirsiniz, terraform plan ile etkiyi önizlersiniz ve değişiklikleri tutarlı şekilde uygularsınız.
Birden fazla kişinin paylaşılan altyapıyı zaman içinde anlaması ve güvenle değiştirmesi gerektiğinde en çok değer kazanan araç budur.
Vagrant, geliştiricilere tek bir Vagrantfile üzerinden bilinen-iyi bir, tutarlı OS düzeyinde ortam sağlar. Bu, işe alım süresini kısaltır, “laptop'ımda çalışıyor” türü sürüklenmeyi ortadan kaldırır ve işletim sistemi paketleri, servisler veya ağla ilgili hataları yeniden üretmeyi kolaylaştırır.
Üretim varsayımları bir konteynerden çok bir VM'e benziyorsa özellikle faydalıdır.
Yerel ortamı (OS, servisler, varsayılanlar) standartlaştırmak için Vagrant; paylaşılan ortamları (ağ, veritabanları, compute, DNS, izinler) standartlaştırmak için Terraform kullanın.
Bağlayıcı fikir, laptop → test → üretim boyunca sabit kalan bir “sözleşme”dir (ör. DATABASE_URL, REDIS_URL, portlar, servislerin varlığı).
Yeniden kullanılabilir yapı bloklarını paylaşılan tutup ortamlara özgü ayarları ince tutan bir yapı önerilir:
/infra/modules gibi bir yerde tutun/infra/envs/dev, /infra/envs/prod)/vagrant içinde toplayınTerraform “state”, yapılandırmanız ile gerçek kaynaklar arasındaki eşlemeyi hatırlamak içindir: hangi veritabanı örneğinin hangi aws_db_instance ile ilişkili olduğu, ID'leri ve uygulanan son ayarlar gibi.
State duyarlı olabilir—kimlik veya bazen değerler içerebilir—bu yüzden bir kimlik bilgisi gibi ele alınmalıdır:
Drift, altyapının Terraform dışında değiştirildiği durumlarda ortaya çıkar (konsol düzenlemeleri, acil düzeltmeler, otomatik süreçler). Bu, gelecekteki planları şaşırtıcı hâle getirebilir: Terraform manuel değişikliği geri almak isteyebilir veya varsayımlar eşleşmediği için başarısız olabilir.
Drift'i azaltmak için pratik adımlar:
Modülleri, ağ, veritabanı ve hizmet dağıtımı gibi tekrar eden desenleri standartlaştırmak için kullanın. İyi bir modül:
40 değişkenli modüllerden kaçının—çok fazla esneklik genelde karmaşıklık getirir ve teslimatı yavaşlatır.
Konfigürasyon ve gizli bilgileri ayırın:
Vagrantfile içine gömmeyinplan ile apply için farklı izinler ve prod için daha sıkı kontrollerAyrıca state'in hassas tanımlayıcılar içerebileceğini varsayın ve ona göre koruyun.
Ölçeklenebilir ve basit bir boru hattı örneği:
terraform fmt -check ve terraform validate çalıştırınterraform plan üretin ve çıktıyı PR'a ekleyin (artifact veya yorum olarak)terraform apply çalıştırınVagrant CI'nin yerini tutmaz, ama yerelde CI kalitesinde tekrar üretilebilirlik sağlar. Paylaşılan bir Vagrantfile ile herkes aynı OS, paketler ve servis sürümlerini ayağa kaldırıp bir hatayı yeniden üretebilir.
Bu, özellikle:
Bu, ortamlar arası terfi işlemlerini çoğunlukla değişken değişiklikleri ile halleder, kopyala-yapıştır gerektirmez.
Bu, değişikliklerin denetlenebilir olmasını sağlar: gözden geçirenler “ne değişecek?” sorusuna uygulama olmadan yanıt verebilirler.