Daha büyük bir organizasyonu destekleyen küçük bir programlama ekibinde çalışıyorum. Bu yıl yöneticimiz, şirket verilerimizin büyük çoğunluğunu işlemek için Oracle Apex teknolojilerini kullanacağımıza karar verdi.

Sadece bir Apex sunucumuz olması dışında bu sorun olmaz. Yöneticimiz her şeyin bu durumda olduğunu kararlaştırdı. Ekibimiz uygulamaları geliştirirken, yöneticimiz onları demoyor ve dahili müşterilerimiz bunları kullanıyor, bu da açık nedenlerden dolayı zaten sorunlara neden oluyor!

Apex'e daha fazla yatırım yaptığımız, uygulamaların daha karmaşık hale geldiği ve kullanıcı sayısı arttıkça bunun daha da kötüleşmesini bekleyebilirim. En iyi uygulamanın ayrı geliştirme, test ve üretim ortamlarına sahip olmak olduğunu duydum, ama neden böyle?

Soru: Neden ayrı geliştirme, test ve üretim ortamlarına sahip olmalıyız?

Neden ayrı geliştirme, test ve üretim ortamlarımız olmalı?

Aynı anda devam eden birkaç etkinliğiniz var:

• geliştirme - geliştiricilerin kod yaptıkları, hata yaptıkları, deneme vb ...
• test - testlerin yapıldığı, manuel veya otomatik olduğu ve karmaşıklık nedeniyle çok fazla kaynak tüketebilir.
• üretim - müşteriler ve / veya işletme için değer yaratılır

Tüm bunların aynı ortamda olmasını ister misiniz? Yeni bir test sunucularınızı sabit sürücüleri değiştirmeye ittiğinden ve işlemcideki her çekirdeği tükettiğinden, işletmenin durma noktasına gelmesini istiyor musunuz? Bir geliştirici, bir ölçeklendirme denemesinden kıvrık bir çatal bombası yaptığı için testlerinizin durmasını istiyor musunuz? Testlerde bir geliştiricinin sicim ve koli bandı nedeniyle çalıştığını düşündüğünüz kodun üretimde çalışmasını istiyor musunuz? Geliştiricilerin potansiyel olarak hassas üretim verileriyle çalışmasını istiyor musunuz (bunun tüm işletmeler için bir endişe olmadığını, ancak bunların çoğunda olduğunu biliyorum)?

Bu sorunların olmasını engelleyen nedir?

Ayrı ortamlar.

Neye ihtiyacın var?

Ayrı ortamlara ihtiyacınız var.

Resmi olarak koymak için

Aşağıdaki nedenlerden dolayı ayrı ortamlara ihtiyacınız vardır:

• iş ve yazılım geliştirmeyi engelleme risklerini azaltmak.
• geliştiricilerin geçici donanımları nedeniyle testleri geçen kodları üretime sokma risklerini azaltmak.
• üretim verilerinin yanlış ellere geçme risklerini azaltmak (organizasyonlar kimlik numaraları, finansal ve sağlık bilgileri gibi hassas verilerle uğraştığında çok önemlidir) veya test verileriyle karıştığında veya yok edildiğinde.

Bağlamınız için yeni bir teknoloji platformu

Belki de bu henüz gerçek bir üretim değildir (nispeten yeni bir platform olduğu için), ancak iş buna güvenmeye başladığında ayrı ortamlarınızı alacaksınız ve ya riski öğrenecek ya da zor öğrenerek gerçekleştirecek kadar akıllılar. yol.

En iyi uygulamanın ayrı geliştirme, test ve üretim ortamlarına sahip olmak olduğunu duydum, ama neden böyle?

Bugünlerde o kadar açık bir kesim değil.

Birçok yerde artık manuel test yapılmamaktadır, bu nedenle kendi başına test verisine sahip değildir. Daha pek çok yer o kadar ölçeğe sahip ki, maliyet nedeniyle üretim ortamlarını yeniden üretemiyorlar. Ve özellikle mikro hizmetlerin patlayıcı büyümesi ile, hızlı bir şekilde değişen ortamları bir QA ortamında test edilmesinin, üretimde ortaya çıkacak hataları yakalamak için işleri doğru bir şekilde üretmesini sağlayacak kadar senkronize tutmak zorlaşıyor.

Neden ayrı geliştirme, test ve üretim ortamlarımız olmalı?

• Test verilerinizin kullanıcılar tarafından görülmesi çok kötü olurdu.
• Ürün verilerinizin devs / test kullanıcıları tarafından görülmesi çok kötü olurdu.
• Geliştiricilerinize kötü şeyler kırmamalarına güvenemiyorsanız ve bu durumu hızlı bir şekilde düzeltemezseniz.
• Eğer otomatik olarak CI kodunu yükseltmek hızlı ve kolay olacak şekilde yerinde varsa.

Esasen, çevreye sahip olmanın maliyeti çevreye sahip olmamanın maliyetinden düşükse .

Ana (ve en belirgin) neden, test ve üretim verilerini asla karıştırmak istememenizdir. Bu, hem sistem kullanıcıları hem de geliştiriciler için inanılmaz derecede kafa karıştırıcı olabilir. Kalite güvencesi ve birim testleri (yapmanız gereken) uygularken, bunların tamamen ayrılmış bir ortamda olduklarından emin olmanız gerekir. Geliştirme ortamınızda veya KG'de bir şey patlarsa, üretimi ve dolayısıyla canlı kullanıcıları ve önemli verilerini olumsuz etkiler! Bunun üretimi etkilemesini kesinlikle istemiyorsunuz!

Bu, sürüm kontrolünüz gibi günlük işlerinizde kullanmanız gereken normal hizmetleri kapsar. Kontrol ettiğiniz kod canlı bir ortamdaysa sürüm kontrolünü düzgün bir şekilde kullanamazsınız! Kullanıcılarınız delirecek - ya geri dönmeniz ya da geri almanız gerekiyorsa? Onbeş derin bir hata yaparsanız ne olur? Dallanma ile nasıl başa çıkacaksınız?

En azından, ortamınızı birkaç sanal örneğe ayırmanız gerekir, ancak gerçekten söylediklerinizi tam olarak yapmanız ve her ortam için tamamen ayrı örneklere sahip olmanız gerekir; ideal geliştirme, KG, evreleme ve üretim.

Tüm bunlar nihayetinde sadece ön taraftaki uygulamanıza (ve böylece kullanıcılarınızla olan itibarınıza) değil, aynı zamanda ekibinizin verimliliğine de komik bir zarar verir.

Yalnızca bir Oracle örneğinin bulunması "geliştirici, test ve üretim ortamları arasında ayrım yok" anlamına gelmez!

Bir yorum yazdınız

Şu anda farklı projeler için farklı şemalar kullanıyoruz

Ok, bu nedenle sadece gelişim için bazı projeler ithaf ve test etmek için bazıları tarafından, sen yapabilirsiniz farklı şemalar kullanılarak, bir dereceye kadar da ortamları ayırın. Sanırım bunu zaten yaptınız, çünkü örnek ayrımı planlanmadığında bildiğim tek mantıklı yaklaşım bu. Yöneticinizin o kadar çılgın olduğunu düşünemiyorum ki, dev verilerini, test verilerini ve müşteri verilerini tek bir şemada rastgele bir şekilde karıştırmanızı istiyor. Muhtemelen sadece ikinci bir sunucu satın almamak ya da ikinci bir örnek için lisansa para yatırmak istemez.

Bu nedenle, sormanız gereken gerçek soru:

Geliştirme, test ve üretim ortamlarını ayırmak için farklı örnekler ve / veya sunucular kullanmamız mı gerekiyor yoksa şema ayırma yeterli mi?

Bu da cevabı, buradaki diğer cevaplardaki kadar net değil. Farklı şemalar farklı erişim haklarına izin verir, böylece en azından bir Oracle örneğinin içinde belirli bir dereceye kadar izolasyon elde edebilirsiniz. Bununla birlikte, geliştiricilerinizin büyük olasılıkla "şemaları" içinde bazı idari haklara ihtiyaçları olacaktır, bu nedenle yalnızca bir örneği kullanırsanız üretim verilerine erişemeyeceklerinden emin olmak daha zor olacaktır.

Ayrıca, bir örnek / bir sunucu aynı zamanda geliştirici, test ve üretim - paylaşılan kullanıcı / şema yönetimi, paylaşılan disk alanı, paylaşılan CPU'lar, paylaşılan ağ bant genişliği arasındaki paylaşılan kaynaklar anlamına gelir. Bunu "sızdıran soyutlamalar yasası" ile birleştirdiğinizde , sadece bir örnek kullanmanın geliştirici, test ve ürün ortamı arasında istenmeyen yan etkiler alma riski olduğu açıktır.

Sonunda kendiniz karar vermelisiniz: Yaklaşımın dezavantajlarıyla etkili bir şekilde çalışabilir misiniz? Uygulamanız o kadar kaynak yoğun değil mi ve üretim verileriniz o kadar "gizli" değil, dev, test ve üretim arasında "üç örnek / üç sunucudan" alacağınız düzeyden daha düşük bir ayrım düzeyine sahip olunması tolere edilebilir. yaklaşmak? Bu şekilde etkili bir şekilde çalışamazsanız veya müşterileri kaybetmeye başladığınız şekilde üretime müdahale etme riski yüksek değilse, yöneticinizi en az ikinci bir sunucu almaya ikna etmek için ihtiyacınız olan tüm argümanlara sahipsiniz.

Birden fazla ortam türüne ve hatta her ortam için birden çok sunucuya ihtiyacınız vardır.

Geliştiriciler geliştirme aşamasında kodu güncelleyebilir. Kod çalışmayabilir - belki uygulama bile başlamaz.

Bu, kendi ortamlarındaki en son kararlı yapıyı test eden KG'yi etkilemez.

Hem geliştirme hem de KG ortamlarını güncellediğinden, üretim altı ay öncesine ait en son sürümde yer alıyor ve diğer ortamlardaki değişikliklerden etkilenmiyor.

Çeşitli ortamlarda sunulan bu değişiklikler kod veya veri olabilir. Belki de KG, üretimdeki bazı kötü verileri düzeltmek için tasarlanmış bir veritabanı komut dosyasını test etmelidir. Belki komut dosyası sorunu daha da kötüleştirir - bir veritabanı yedeklemesini geri yükleyin ve tekrar deneyin. Eğer bu üretimde olsaydı, çok ciddi bir mali sorununuz olabilir.

Birden fazla sürümünüz varsa ne olur? Belki sürüm 2.0 geliştiriyorsunuz, ancak yine de 1.0 bakım dalında hata düzeltme sürümlerine ihtiyacınız var. Artık, kritik bir hata bulunduğunda ve dün düzeltilmesi gerektiğinde her iki dalı da geliştirip test edebilmeniz için birden fazla geliştirme ve KG ortamına ihtiyacınız var.

Ayrı ortamlara sahip olmamanın neden olduğu sorunları zaten fark ettiniz . Burada ayrı ortamların temel nedeni var: geliştirme, test ve üretim operasyonlarını tek bir ortamda yapmaya çalışırken kaçınılmaz olarak ortaya çıkan çatışmaların yol açtığı sorunları ortadan kaldırmak. Aynı gerekçe, geliştiricilere çalışmak için bireysel sanal alanların verilmesi için de geçerlidir, bir geliştiricinin hatalarını ve hatta tüm geliştirme ekibini sakatlamaktan kaynaklanan uyumsuz değişiklikleri korur.

Bu aynı zamanda tek bir ortamdan uzaklaşmak için yönetime yapabileceğiniz en iyi argüman: tek bir ortamın zaten neden olduğu sorunlara işaret etmek, trend çizgisini göstermek ve bir şeylerin orada olduğu gibi devam ederse er ya da geç olduğunu iddia etmek temizlik için çok daha pahalıya mal olacak (hem doğrudan çaba içinde hem de şirketinizin hizmet sunma yeteneğine olan güven kaybı), işleri ayrı ortamlar için yeniden yapılandırmaktan daha pahalıya mal olacaktır.

Birçok karşıt güç ve dinamik var. Birçok sunucuya sahip olma maliyeti ve sadece bir sunucuya sahip olma maliyeti vardır. Bu soru sadece veritabanı daha telate olabilir düşünüyorum? Yanlış anlama olabilirim, ama soyut olanlara kıyasla soyut olanların maliyetlerinin yeniden ortaya çıktığı sistemik bir yanlış anlama ile ilgilidir.

Tipik olarak bariz maliyetlerin anlaşılması kolaydır.

Soyut maliyetlerin ölçülmesi daha zor ve dolayısıyla anlaşılması daha zordur. TeknikDebt, hata maliyeti, stres maliyeti, geliştiricilere yük, değişimin etkileri, regresyon testi, kesinti süresinin etkisi vb. Açıklamak daha zordur.

farklı ortamlar Ortamlar genellikle veri ve / veya amaç için ayrılır. Her ortamın farklı bir işlevi vardır. Bir sistemdeki değişim oranı, yani. ne sıklıkta güncelleneceği, ne tür değişiklikler ve değişikliğin etkileri dikkate alınır.

Değişimi önemsizleştirmek için farklı ortamlar kullanıyoruz.

Farklı ortamlar kullanıyoruz, bu nedenle değişmeyen ortamın sağlamlığını ve kesinliğini sunuyoruz.

Bir değişikliğin etkilerini değerlendirmek için ortamları kullanırız.

Değişimle ilgili maliyetleri azaltmak için ortamları kullanıyoruz.

bir sistemi test etmek ve stabilize etmek çok pahalıya mal oluyor Kararlı ortama yapılan yatırımı güvence altına almak için ortamlar yaratıyorsunuz.

Hiçbir zaman pragmatik, maliyet tasarruflu, gayretli ve kanıtlanmış süreç modellerine bağlı kalamayacak kadar küçük değilsiniz.

Her şey için tek bir ortam kullanmak, tüm fotoğraflarınızı tek bir sabit diskte saklamak gibidir, bunu yapabilirsiniz, ancak pişman olacaksınız.

bazı insanların kanıtlanması gerekir Birçok durumda müşterilerle veya sağlamlığı sağlama ve en iyi uygulamaları takip etme maliyetlerini takdir etmeyen başkaları ile ilgileniyorum. Maliyetlerin açıkça tanımlandığı bazı gerçek vaka örnekleri bir araya getirmenizi öneririm.