Birden fazla ortama sahip olmanın iyi, basit nedenleri

Kariyerim boyunca farklı amaçlar için farklı ortamlar topluluğu olan şirketlerde çalıştım. Masaüstü ortamımız, test ortamımız, KG ortamımız, aşamalı ortamımız ve üretim ortamımız her zaman az ya da çok oldu. Bu hem sunucular / uygulamalar hem de kullandığımız veri kaynakları için geçerliydi.

Mevcut şirketimde başladığımda, uygulamaların% 90'ının ya platform ortamında üretim veri kaynaklarına karşı bir masaüstü ortamında geliştirildiğini ya da doğrudan üretim sunucusunda geliştirildiğini gördüm. Bu özellikle şaşırtıcı değildi, çünkü geliştirme ekibinin işleyiş şeklini geliştirmek için değişiklikler yapmak için bir kısmı işe alındım ve bu da görüşme sürecimden açıkça görüldü. Felsefeyi yavaş yavaş değiştirmeye başladık ve çok yakında, uygulamaların çoğu ya masaüstü, test ya da üretim ortamında çalıştırılabilirdi. Bu aşamadan sonra çok uzun sürmedi.

Şimdi geliştiricilerin çoğu bu metodolojinin yararını görüyor ve dikkatli bir şekilde savunuyor. Ancak, hiçbir zaman geçiş yapılmayan eski uygulamalarımız var. Ayrıca, bunu zaman kaybı olarak düşünen bazı eski programcılarımız da var. Ne yazık ki, dudak servisimiz var ama yönetimden asla tam katılım alamadık. Yaklaşık bir yıl önce bu konuya büyük ölçüde yatırım yapma taahhüdünde bulunduğumuzu düşündük, ancak içine koyduğumuz önemli planlamaya rağmen hiçbir şey gerçekleşmedi. Şimdi daha fazla çevreye ihtiyacımız olduğunu buluyoruz. Kurulum için sunucu / ağ yönetimi ekiplerinden yardıma ihtiyacımız var ve yayın döngüsünü desteklemek için işletme paydaşlarının katılımı gerekiyor. Şu anda bir projenin, makul geliştiricilerin "normal" olarak kabul edebileceği şekilde çalışabileceği bir yerdeyiz.

Tam bir argüman sunmayı çok isterdim, ama yönetimin kritik bir mesele olana kadar beni duymak için hiçbir zaman ve ilgisi yok. Faydaları gerçekten bana her zaman sadece ikinci doğası göründüğü gibi açıkça ifade edemiyorum. Yöneticilerin bu fikri desteklemesi için geliştirme deneyimine sahip olmayan ortamların ayrılmasının iyi, basit, reddedilemez sebepleri olup olmadığını merak ediyor muydum? . Konuyla ilgili iyi kaynaklar / literatür var mı?

Cevap: Para

Asıl nedenin ne olduğu umrumda değil. Para, özellikle yönetim ile uğraşırken tüm akıl yürütmelerinizin temelinde olmalı.

İkimiz de bir odada 2 saat oturduktan sonra , birden fazla ortama sahip olmanın neden daha iyi olduğunu gösteren düzinelerce neden bulduk .

Sorun şu: Sebepler paraya dayanmıyorsa, hiçbiri önemli değil .

Programcılar akıllı olmak için işe alınmazlar. Yaratıcı olmak için işe alınmamışlar. Para kazanmak veya para tasarrufu yapmak suretiyle gelirlerini artırmak için işe alınırlar. Bunlardan birini yapmıyorsanız, özgeçmişinizi bir araya getirmeniz iyi olur.

Bu açıdan bakıldığında cevap basit:

Yalnızca bir ortama sahip olmak, aksama süremizi artırır ve gelir kaybına neden olur. Çoklu ortamlar, kullanıcılarımıza şirketimiz kadar güvenilir ve güvenilir bir ön uç vererek karımızı korumamıza olanak tanır.

Her gün tekrarlayın.

Aşağıda bu cevaba gerçek değer katan harika yorumlar var, onlardan bahsedeceğim:

• Karl Bielefeldt'in Maliyet / Fayda analizinin önemli bir faktör olduğunu belirtti. Bir ekonomist, bunu birden fazla ortamı takip etmenin fırsat maliyeti olarak niteleyebilir. Bunu duymak şaşırtıcı olsa da, birden fazla ortamın cevap alamayacağı senaryolar var ! Şirketinizin web sitesi çok küçük bir ekleme ise, beklenmeyen aksama süreleri aslında iş yapmanın daha uygun maliyetli yolu olabilir. Bu, bulunduğunuz konum gibi görünmüyor, ancak bahsetmeye değer.

• BlairHippo'nun bir felaket gibi görünmesini sağlamakta özgürsünüz (ve verilerinizi kaybederseniz, öyle!). Sorumluluk yöneticileri ikna etmek için harika bir araçtır, ancak yine de aynı sebepten dolayı - davalar pahalıdır. Onlardan kaçınmak para tasarrufu sağlar.

Ek olarak, bu makalenin oldukça iyi olduğunu gördüm . Sorunuzu doğrudan cevaplamıyor, ancak programcıların yönetime nasıl baktıklarını tanımanızı sağlar; bu da bu cevaba yol açar. İyi okuma.

Tek başarısızlık noktası

Bir geliştirme veya evreleme ortamına sahip olmadan , bu eski uygulamalar için Tek Bir Hata Noktasına sahipsiniz . Eski uygulamaları bu terimlerle açıklarsanız, Yönetim sizi duyacak.

Mesajınızı kendileri için anlamlı olan ses baytlarında gösterebilmeniz gerekir. " Programmer Speak " ı tartışmadan çıkarın ve " Manager Speak " ile değiştirin . Ayrıca puanınızı almak için 30 saniyelik bir asansör yolculuğu varmış gibi yapın.

Patronumun Piyade Denizcisi olduğu bir durum vardı. Daha verimli olabilmek için Denizcilerim için yazılım araçlarına ve bilgisayar eğitimine ihtiyacım olduğunu söyleyip durdum. O anlamadı. Sonunda bir gün ofisine gittim ve ona her şeyin yolunda gittiğini söyledim.

Etkiye bir şey söyledim ... "Bir savaşla savaşıyorsam çubuk, taş ve ağaç dalları kullanırdım. İhtiyacım olan el bombası, bazuka ve makineli tüfekler." Mesajı aldı.

Gerçekten kritik mi?

Ayrı ortamlar kullanma arzusunu anlayabiliyorum. Açık olmayan soru şudur:

Eski bir sistemi taşımak gerçekten kritik mi?

Teknik olarak düşünen insanların çoğunun, hangi yolun daha iyi olduğu ve akademi'de iyi olan akademik soruya odaklanma eğiliminde olduğunu düşünüyorum. İş dünyasında en iyisi her zaman kazanamaz. Bunun negatif olduğunu ya da alev savaşı başlattığını söylemiyorum. Açıkçası ya da birkaç yıldan beri yazılım sektöründe çalışanlarımız için neyin açık olması gerektiğini belirtiyorum .

Tüm iş kararları tipik olarak algılanan maliyet / faydaya dayanarak verilir. Yani iş muhtemelen soruyor olduğu soru:

Eski bir uygulamadaki ek sistem ve geliştirme yatırımlarının maliyeti, aynı yatırımı başka bir projeye / ürüne koymak yerine, faydaya değer mi?

Yalnızca geçiş / yeniden yazma yazılımında değil, aynı zamanda bir öncülüğün de dahil olduğu günlük kararlarda bile bir karar verebilmek için düzenli maliyet yararı analizini yaptım ve hâlâ yapmaktayım. bu nedenle değer.

Ayırma Ortamları

İş nedenleri ortamları ayırmak için.

• Sürümlerinde daha az risk ve hata düzeltmeleri. Rakamlarla kanıtlayın. Ürün kaç kez başarısız oldu ve kötü bir sürüm / hata nedeniyle müşteri kazancına mal oldu.
• Gelişimde daha az risk. Yanlışlıkla dev db'yi devirme db, üretim db'sini yanlışlıkla uzaklaştırmadan farklıdır.
• Rolleri ve erişimi açıkça ayırma yeteneği yani. daha iyi güvenlik. Üretim pastasındaki parmak sayısını sınırlamak iyi bir şeydir
• Ortamları ayırma yeteneği ve bu gelişim tarzına uygun uygulamalar ve prosedür gelecek için Bulut Sistemlerinde birikime izin verir.
• Çevrenin ayrılması, zamanlanmış ve dinamik ölçeklendirmenin yanı sıra yararlı olabilecek çoğaltma ortamlarındaki etkinlikleri zorlamalıdır.

Halen yerinde olan tüm "doğru" argümanlara sahipsin. Bunun yerine, eğer bir "kırmızı ringa balığı" yaşarsınız. Veya, "havuç kovalamak"

Kritik bir mesele olana kadar yönetimin beni duymak için hiçbir zaman ve ilgisi yok

Asıl sorun olarak düşündüğüm şey bu. Tecrübelerime göre, bir şirketin tanımladığı kadar düşük geliştirme uygulamaları varsa. Bu sadece "daha iyisini bilmiyorduk" meselesi değil. Aksine, sunduğu problemleri bilmeyen (önemseyen) bir üst yönetim ekibinin neden olduğu teknik borcun bir derlemesidir.

Bu gibi durumlarda, iyi bir konuşma, aniden yönünüzü değiştirecek bir şey olmayacak. Belki şiddetli bir travma (müşteriye görünür ve doğrudan kötü uygulamalarla bağlanmış ürün hatası), ama siz konuşmayı denemeden önce aklı başında meraklı teknolojiler var.

Benim önerim, ya onları emmek ve ne oldukları için bir şeyler almak ya da yeni bir pozisyon aramaktır.

Bir seferde kaç insan grubu uygulama üzerinde çalışmayı planlıyor? Genellikle, her insan grubu için bir ortam gördüm. Bu Geliştiriciler (bir DEV ortamı ve bir DEV Entegrasyon ortamı elde ediyorlar - bazıları% 100 gerekli değil, projeye göre değişir diyebilirim), iki test ortamı (çok detaylı test yapan bir grup test cihazı, diğeri için üst düzey KG test uzmanları - genellikle eğitimli test uzmanları değil gerçek iş kullanıcılarıdır). Ayrıca genellikle izole edilmiş bir Performans test ortamı da vardır (böylece büyük hacimli verileri test edebilir, büyük hacimli kullanıcıları simüle edebilirsiniz, vb.).

Neden tüm bu ortamlar? Böylece farklı gruplar birbirlerinin ayak parmaklarına basmadan farklı özellikleri test edebilir. Geliştiriciler ve test cihazları aynı ortamda çalışıyorsa, bu bir kabustur: bir test cihazı, bir geliştirici tarafından her dakika aktif olarak değiştirilen bir özellik üzerinde bir kusur açabilir. İki test seviyesi varsa, farklı aktivitelere odaklanabilir ve birbirlerinin verilerini karıştırmaktan endişe duymazlar. Yalıtılmış bir performans ortamına sahip olmak, makineyi asabilecek testler yapmanıza olanak sağlar, ancak yalıtılırsa, başka hiçbir test cihazı etkilenmez.

Çok fazla insan aynı ortamda çok fazla farklı şey yapmaya çalıştığında, bir grubun başka bir grubun testini bitirmesini beklemesi için çok fazla boşa zaman harcarsınız, böylece kendi gruplarını çalıştırabilirler. Ve bu zaman harcar ve boşa harcanan zaman, Stargazer712'nin en güçlü düzenlemeyi yapabileceğine işaret ettiği boşa para harcayabilir.

Başka bir neden (yaygın değil) veridir: Uygulamanızın hassas kişisel verileri veya kredi kartı verileri varsa, genellikle bunu test ortamlarına koyamazsınız ve genellikle Kalite Güvencesi ve Üretim ortamları dışındaki her şey için maskeleme gereksinimleri vardır.

İş yerinizde kültürel bir değişim sağlamak için çok çaba harcadınız. Değişim çoğu zaman zor olduğu için bu büyük bir başarıdır, ancak kültürel değişim sadece insanların zihinlerini değiştirmekle ilgili değil, alışkanlıkları değiştirmek, önyargıları kırmak ve nihayetinde potansiyel olarak kapalı zihinleri daha büyük olasılıklara açmakla ilgilidir. Yani bu noktada kendinize sormanız gereken soru "Neyi özledim?". Kolay cevap, yönetimle tam olarak ilgilenmemiş olmanız olabilir.

Yönetimden alım yapmak kolaydır, ancak daha da zorlaşmak kabullenmek demektir. Para vs. hakkındaki argümanlardan bağımsız olarak, gerçek şu ki, yönetimin öncelik görüşünü etkileyebilmeniz gerekir. Yöneticiniz bir bütçeye sahip olacak ve bütçenin makul bir şekilde ve şirket değerleri ve öncelikleri doğrultusunda uygulandığını göstermek isteyecektir. Bu önceliklerden bazıları mali olacak, ancak diğerleri başka ihtiyaçlara cevap vermekle ilgili olacak. Bazı durumlarda bu, patronunuzun her zaman istediği terfi almak için diğer yöneticilerin avuçlarını yağlamak anlamına gelebilir. Yine de çoğu durumda, daha fazla iş kazanmanın veya iş ortakları ve müşterilerle ilişkileri geliştirmenin yollarını bulma olasılığı olacaktır. Davanızı bu şartlarda yerine getiremezseniz, kendinizi bir çıkmaza sokmadan çok önce gidebilirsiniz.

Önerim, başkalarının önerdiği gibi verimlilik ve bunun bütçeyi nasıl etkilediğiyle ilgili bir dava açmaya çalışmak, aynı zamanda şirketinizin öncelikleri ve verimliliğinizin şirketin diğer şirketler ile olan ilişkilerini doğrudan nasıl etkileyebileceği konusunda da bir dava açmak.

İşte bir tane: test edilebilirlik.

Bir test ortamına sahip olmak, size bir üretim ortamında gerçekleştirilmesi tavsiye edilemeyecek bir veri tabanında test yapma özgürlüğü verir.

Kuruluşunuzun yazılımını nasıl geliştirdiğini değiştirmek ister misiniz? "Farklı şeyler yapmak" için "sebepler" hakkında endişelenmeyi unutun. İnsan rasyonel argümanlardan dolayı davranışını değiştirmez. Alışkanlıkları üzerindeki psikolojik etkiler nedeniyle değişiyorlar.

Peki bununla nereye gidiyorum?

İken bazen başarıyla tartışma yoluyla bir kuruluşun davranışını değiştirebilir, daha iyi çalışan diğer taktikler vardır. Bunlar şunları içerir:

• Grassroots desteği: Size bir şans vermek isteyen bir tane "eski" geliştirici bulun. Onunla ortak ol ve işlerin nasıl yürüdüğünü değiştir. Değişikliği açıklama. Sadece değişikliği yap. Biri senden bir şey sorarsa, "Ah evet, şimdi böyle yaparız" de.

• Sorumluluğu devralmak. Eski millet için konuşmalar yapmak için gönüllü olun. Sevdiğin gibi davran. Bu sorumluluğu bırakmaktan mutlu olabilirler. Ardından istediğiniz şekilde çalıştırın.

• Hatalarından dolayı doğru insanları suçla. Bir dahaki sefere bir uygulama hatası, taş devri dağıtım mekanizmanız nedeniyle üretime girdiğinde, dikkatinizi çeker. Nazikçe yapın ... Bir e-postada değil. Bir dahaki sefere bir yöneticiyle bir toplantıda olduğunuzda, konuşlandırmanın sorunlu olmasının bir sebebi örneğini açıkça belirtiniz. “Evet, geçen Cuma günü Bob'un üretime giriş yaptığı Foo böceği yüzünden nasıl mücadele ettiğimizi hatırlıyor musunuz? Evet, çok fazla çaba harcandı!”

• Daha iyi bir şekilde yapmayı kolaylaştırın. Örneğin iphone'a bakın. Üzerinde bir tane düğme var. (Peki, iki). Açmak ÇOK kolay. Birden çok çevreye dağıtım yapmak çok kolay. Tüm yöneticilerin yapabileceği kadar kolay!

Bağlantılı veya eski sistemlerle uğraşmaya başladığınızda bunun daha fazla bir sorun olması, işin çalışmaya ve doğru olmasına bağlı olduğu sistemlerdir. Bu önemlidir, çünkü aşamalar arasında ayrıştırma yapılması gerekir, PROD üzerinde DEV yapmamanızın nedeni , kayıp zamanda milyonlarca dolar değerinde zarar verebilecek potansiyele sahip olmasıdır .

Her zaman DEV -> QA -> PROD (bazen bu adımlar daha küçük parçalara bölünür) arkalarında aynı donanımla yaparız. Mevcut üretim verileri daima PROD'dan QA'ya ve DEV'ye itilir.

DEV: Bu ortamdaki herhangi bir veride işlerin denendiği, tekrarlandığı ve dövdüğü hiçbir zaman güvenilmemeli ve geliştiriciler tarafından basitçe bir problemi çözmenin yollarını bulmaya çalışılan geliştirme sanal alanı olarak düşünülmüştür.

QA: Geliştiricileriniz birim testlerinden memnun olduklarında, test grubunun oraya göz kulak olma zamanı. Test senaryoları çalıştırıyorlar, performans testleri yapıyorlar ve hata buluyorlar. Bu hatalar / iyileştirmeler DEV'ye geri beslenir ve herkes mutlu olana kadar döngü devam eder.

PROD: Bu aşamaya geldiğinizde, kodun mevcut verilerle birlikte çalıştığından ve KG grubunuz / işletme kullanıcılarınızın uygulamadan memnun olduğundan emin olmalısınız. Her şeyi doğru yaptıysanız, kodu güncelleyebilmeli ve onunla yapmalısınız.

Aynı şekilde, müşterilere test edilmemiş bir ürünü asla serbest bırakmazsınız, test edilmemiş kodu asla üretim ortamına bırakmamalısınız.

Şirket uygun şekilde yapmak için zaman ayırmaya istekli değilse, acil bakım masraflarını ve 10 kat hatalarını geri ödeyeceklerdir.

Küçük bir örnek olarak: Üretim raporunda tek başına değişiklik yapmaya karar veren bir şirketimiz vardı. Hiç kimse, bir ya da iki yıl boyunca çeşitli meseleleri ele almaya gelinceye kadar değiştiğini bilmiyordu.

Rapordaki usulsüzlüğü belirttiğimizde, CFO'nun yüzü beyazlaştı, birisinin çabucak değişiklik yaptığı için çeyrek yılda ~ 250.000 dolar kaybediyorlar.

Daha sık gerçekleşir sonra düşünürsünüz, düzgün yapmayı göze alamazsanız, o zaman yapmayın.

Yönetim, bu ortamları oluşturmak için gereken Yazılım Şirketlerinin ve Yazılım Ürünlerinin başarısının arkasında büyük bir yere sahiptir. Projenizden bir örnek alalım. Yazılımınız büyük çapta geliştirildiyse, proje gereksinimlerinizi, süreç kontrolünüzü, Test Yapımlarını vb. Yönetemezseniz, bu başarısızlık olasılığıdır. Böylece Proje Yönetimi var.

@ Stargazer712'de ifadenizin Para ile ilgili olduğuna işaret ettiğini biraz kabul ediyorum, ancak Marc Hamilton'un Yazılım Geliştirme kitabından aldığım şu ifadeyi kontrol edin: Güvenilir Sistemler Oluşturma (Prentice Hall PTR, 1999, ISBN 0-13-081246- 3). Tüm bu faktörlere baktıktan sonra; Sorunuz hakkındaki düşüncem Tek Çevre'nin size tasarruf sağlamadığı, proje / yazılımın tamamlanması için uzun vadeli bir süreç olacağı yönünde. Dağıtılmış Ortamlar, deneyimimde öğrendiğim ve gördüğüm gibi, kazancımı başlattığım başlangıç ​​yazılım şirketlerinde olanların ne olduğunu öğrendiğim gibi zamandan ve gelirlerden tasarruf edecek.

Başarı için neyin önemli olduğunu gösteren birçok makale var. Bunu kontrol edin Başarılı Yazılım Geliştirme için Organizasyon Yapın

Bir organizasyondaki her bireyin belirli yetenekleri vardır ve bu beceriler tipik olarak gelecekteki performans için teşvikler olarak ödüllere (tazminat) yol açan resmi veya gayri resmi performans ölçütlerine göre ölçülür. Bir organizasyondaki insanlar kendi kültürlerini kurarlar - bu davranış kalıpları ve genel olarak benimsendiği kabul edilen değerler.

Çok sayıda yazılım geliştiricisi, zamanlarını uygun olmayan bir organizasyonel yapıya karşı mücadele etmek zorunda kalmak zorunda kalırlarsa, hedeflerine ulaşmak için mücadele eder ve nihayetinde başarısız olur.

Pek çok yazılım başlangıcı, bir garajda çalışan birkaç geliştiriciden daha fazlasıyla hayata başlar. Bir şirketin tarihinde bu noktada çok fazla örgütsel yapı gerekli değildir, ancak örgütsel yapı halen mevcuttur. Örneğin, 1977'de Bill Gates ve Paul Allen ortaklığını kurdular ve resmen Microsoft olarak adlandırdılar, şirket minimum organizasyon yapısına sahipti. Bir düzineden az çalışanı Microsoft'un New Mexico'daki Albuquerque'deki ilk ofisinde çalıştı ve herkes kimin sorumlu olduğunu biliyordu. Herkesin raporlama yapısını bulmak için karmaşık bir organizasyon şemasına gerek yoktu. Aynı zamanda, tüm çalışanlar şirketteki rollerini ve neler başarmaya çalıştıklarını biliyorlardı. Bunun nedeni, ihtiyaç duyulan herhangi bir organizasyon yapısının çalışanların her biri arasında gayri resmi olarak iletilebilmesi idi.

Nasıl ... zaman, para, test edilebilirlik, kalite unut itibar .

iyi, basit, reddedilemez nedenleri olan yöneticilerin bu deneyimi desteklemek için geliştirme deneyiminden yoksun yöneticileri alacak ortamların ayrılması.

Uber kısa süre önce, canlı ortamları için şifreler içeren github'a kod göndererek , bilgisayar korsanlarının tüm müşteri ayrıntılarını indirmesine izin verdi. Uber, ihlal olduğunu söylüyor, herkes "kamuya açık kilitlere anahtarlar koymayın. Geliştiricileri tamamen dev bir ortamda çalışıyorsa, github üzerindeki dev ortamlarının anahtarlarını bırakmış olabilirler, ama bu tamamen Zararsız: Üreticilerin serbest bırakılmasının, üretim ortamı üzerinde bu geliştirme fikrinin ne kadar zayıf olduğunu gösteriyor.

Sadece yöneticinize hatalar olduğunu hatırlatın, bu yüzden gazetecilerin önünde bir ızgara yapmak üzere olan ve teknoloji halkı tarafından güldürülen CEO’nun önüne geçmeden kaçınmanın yolu, bu hataların yıkıcı olmasını önlemek için basit ve açık adımlar atmaktır. olanlar.

Farklı ortamlara ihtiyacınız var gibi görünüyor ve bir "ortam" kurmak insanlara çok zaman harcıyor.

Kurtulabileceğiniz en az sayıda farklı "ortamlara" sahip olmalısınız, ancak siz ve şirketin arzu ettiği kadar çok nedenle (sistem yapılandırması için "ortamı kullanarak) istediğiniz kadar kopyalayabilirsiniz ."

Optimal olarak, tek farklar şöyle olmalıdır:

1. Boyut (en az, önerilen, en büyük desteklenen / karşı test edilen);
2. Evreleme ve üretim geliştirme araçlarına sahip değildir
3. Üretim, verilerin yanlışlıkla üzerine yazılmasına karşı korunur
4. Demo, test veya [anoymized] müşteri verilerini geliştirme veya aşamalı sunuculara kolayca yükleyebilirsiniz

Daha sonra ne kadar ve ne tür bir test yapılması gerektiği sorusu bir risk / maliyet iş değerlendirmesidir ve şirket düzeyinde kararlaştırılır, çünkü önemli hatalar bir dizi müşteriye ulaşırsa sıkıntı çekecek bir iştir. .

Daha Sonra Düzenleme: Bu, isimlendirme sözleşmelerimi web ürünlerimle rasyonelleştirmemi istedi (soru için teşekkürler). Qa (yalnızca test işlevselliğini sağlamak için minimum tek katmanlı) ve aşamalandırma (yük / performans / hacim testi için üretim ile aynı yapıya sahip) arasındaki test bölünmesiyle dört "ortama" karar verdim.

Hazırlamadaki tek gerçek fark üretim / aşamalandırmadır; farklı sunucuların hangi gruplarda olduğunu kontrol ettiğim ayrı bir sisteme bir DB kurmak. Qa / dev'in hem web sunucusu hem de db rolleri vardır. Yük dengeleme cloudflare tarafından yapılır.

Ayrıca, sistemlere iletilen bir ENV_NO değişkenine sahibim, böylece istediğim kadar "qa" veya "evreleme" örneğine sahip olmayı seçebilirim.

Bu yüzden, canlıdan en son yedeklememi içeren ikinci bir qa ortamı oluşturmak için komutlar şöyle olacaktır:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

Son olarak, yere vurmadan önce son güvenlik ağı olarak "salt okunur" adında bir ekstra (isteğe bağlı) sunucu var. Bir qa sistemi gibi hazırlanmıştır, ancak dün geceleri yedekleme ve güncelleme devre dışı bırakılmıştır (yazılım aynı zamanda dün geceye güncellenmiştir).

"Farklı bir sepetteki tüm yumurtalar" yaklaşımını kullanır: Farklı bir lokasyon / DNS kayıt şirketi, DNS sunucusu, sistem sunucusu servis sağlayıcıları ile sağlanır. Bu en üst düzey / son güvenlik ağıdır, böylece her şey alevler içinde kaldıysa, en azından dün geceye kadar verilere ulaşabilirsiniz. Temel hazırlık komut dosyaları, farklı sağlayıcılar arasındaki farkı izole eder, bu nedenle% 99 aynıdır, sadece salt okunur bayraktır. Cloudflare yük dengeleyici, tüm canlı sunucular başarısız olduğunda trafiği salt okunur siteye yönlendirir.

Bir değişiklik yapmak söz konusu olduğunda, yalnızca profesyonel görüşünüzü dinleyecek ve önerilen değişiklikleri uygulayacak birine sahip olduğunuz için şanslısınız.

Tecrübelerime göre, büyük bir değişiklik yapmak zorunda kaldığım her seferinde, işletmenin yapacağı tasarruflar açısından haklı göstermek zorunda kaldım. Örneğin, ReSharper'ı geliştirme boru hattına sokmak oldukça kolaydı, çünkü şu satırlarda bir şeyler söyleyebilirim:

ReSharper, geliştirici başına yaklaşık £ 50 tutarındadır. Yıllık ortalama geliştirici maliyeti £ 40k'dır. ReSharper, geliştiricinin verimliliğini, tüm potansiyeline alıştığından en az% 20 oranında arttırmalıdır. Diyelim ki geliştirici zamanının% 75'ini aslında IDE'ye kod yazarak geçiriyor. 40k’nin% 75’i 30k TL’dir. £ 30k şimdi geliştiricinin üretkenliğinin maliyetidir. Yılda ek bir yüzde verimlilik (% 1) 300 £ tutarındadır. % 20 daha fazla üretkenlik elde etmek için, işletme 6 bin sterlin harcamak zorunda kalacak.

Bunu işletmeye perspektifinize sokacak olursanız, başka birini işe alabileceğinizi ve 6k sterlin için% 20 ek verim alabileceğinizi ya da bir ReSharper lisansına 50 sterlin harcayarak aynı sonucu elde edebileceğinizi söyleyebilirsiniz. Rakamlar işin önüne geçince, karar vermek kolay olacak.

Şimdi birden fazla ortama sahip sorularınızla ilgili olarak, yapmanız gereken tek şey, bu ortamlara sahip olmak için her yıl işletmeye ne kadara mal olacağını hesaplamanın bir yolunu bulmak.

Diğer geliştiricilerden geliştirme, uygulama vb. Uygulamaları yapılandırmak için her hafta harcanan saatleri takip etmelerini isteyebilirsiniz. Gelişmeye harcanabilecek 10 saat veya çok daha önemli bir şey. Rakamları bir süre toplarsınız ve işletmeye yıllık maliyet sağlarsınız.

Şahsen bu tür politikalardan nefret ediyorum ama bu yaygın ve bununla birlikte yaşamak zorundayız.