Salesforce Sürüm Treni: Sürüm Yönetimine Pratik Bir Yaklaşım

Sürüm yönetimi, adından da anlaşılacağı gibi, farklı aşamalar ve ortamlarda bir yazılım derlemesini yönetme, planlama, programlama ve kontrol etme sürecidir; yazılım sürümlerini test etme ve dağıtma dahil (Humble & Farley, 2011).

Bu başlı başına oldukça büyük bir konudur ve ancak geliştirme ekipleriyle farklı yinelemeler denenerek ve iş gereksinimleri veya özellik sürümleriyle eşleşerek zaman içinde mükemmelleştirilebilir. Bir organizasyonun serbest bırakma trenini yönetmek için meta veri yönetimi, CI oluşturma ve korumalı alan yönetiminin sektör uygulamalarını ele almaya çalışacağız.

Ama serbest bırakma treni nedir?

Serbest bırakma dizisi, artımlı ve öngörülebilir bir özellik teslim tekniğidir. Geliştiricinin, geliştirme ortamında yapılan değişiklikleri alması ve bunları üretime dağıtması için resmi bir süreç oluşturmasını gerektirir.

Bir serbest bırakma treni genel olarak üç bölüme ayrılabilir:

• Meta veri yönetimi
• Sürekli entegrasyon oluşturma
• Korumalı alan yönetimi

Meta Veri Yönetimi

Meta veriler, diğer veriler hakkında bilgi sağlayan verilerdir. Salesforce, Meta Veri API'si aracılığıyla zengin ve güçlü bir meta veri modeli sağlar. Uygulama meta verileriniz, kuruluşunuzun kaynak koduna ve yapılandırmasına programlı erişim sağlayan bir dizi yöntemi tanımlar ve kapsar.

Meta Veri API'si, Salesforce'ta özelleştirmeleri yönetmenin en iyi yoludur. create , read , update ve delete yöntemlerini destekler. Meta verileri bir kuruluştan diğerine taşımak için Değişiklik Kümeleri, Force.com IDE ve Ant Migration Tool'u kullanabilirsiniz, çünkü bunların tümü API aracılığıyla geçiş sağlar.

Her aracın kendi avantajları vardır ve birini seçerken göz önünde bulundurulması gereken birkaç şey vardır:

Tablo 1: Meta Veri Geçişi için Araç Karşılaştırması

Meta Veri API'si, Force.com platformunda değişiklikleri geliştirirken ve taşırken amacına hizmet etmede harikadır. Ancak küçük bir yakalama var - Salesforce meta verilerinin tümü Meta Veri API'si tarafından desteklenmiyor. Resmi belgeler, desteklenmeyen bileşenlerin bir listesini sağlar.

Kuruluşunuz Meta Veri API'si tarafından desteklenmeyen değişiklikler yapıyorsa, bu değişiklikleri hedef kuruluşta manuel olarak çoğalttığınızdan emin olmanız gerekir. Bu değişiklikleri izlemenin en iyi yolu bir elektronik tablodur. Bu yaklaşıma başvurmanız gerekiyorsa, bu değişiklikleri tek bir kişinin yapması ve izlemesi her zaman tavsiye edilir.

Bu, bir elektronik tabloda bu değişiklikleri izlemek için kullanılabilecek iyi bir genel sütun listesi olacaktır:

• Bileşenin adı
• Bileşen türü
• Sahibi değiştir
• İşlev açıklaması
• Yetenek haritalama
• Diğer bileşenlerle bağımlılık
• İncelenen/inceleyen adı
• URL
• Kuruluş adı/kimliği
• Diğer yorumlar

Sürüm Kontrolü ve Sürekli Entegrasyon

Değişikliklerin üretime geçişi sorunsuz bir süreç olmalıdır, çünkü bu yalnızca, test ve hazırlama ortamındaki değişikliklerin uygulanmasının bir tekrarıdır. Yine de, her zaman bir şeylerin güneye gitme olasılığı vardır ve o zaman bir geri dönüş planına ihtiyacınız vardır. Kuruluşunuzun meta verilerinin yedeğini tutmak çok önemlidir ve sürüm kontrolü ve CI derlemesi bunun içindir.

Sürüm kontrolü, herhangi bir kuruluş için mutlak bir zorunluluktur. Geliştiricilerin işbirliğine dayalı, verimli ve güvenli bir şekilde çalışmasına olanak tanır. Çoklu geliştirici, çoklu sanal alan kod geliştirme ve geçişini yönetmek, Salesforce'ta zorlu bir iştir. Salesforce'un ayrıca sürümler ve bakım için kendi programı vardır. Bu güncellemeler yeni özellikler sunar, ancak Meta Veri API'sinde CI yapınızı bozabilecek bir değişiklik getirebilirler. Bu nedenle, geliştiricilerin birbirlerinin değişikliklerinin üzerine yazdığı durumlar dışında, sürüm kontrolü bir geri alma stratejisi oluşturmanıza yardımcı olur. Uygulamanız Force.com'da çalıştığında geri alma stratejisine sahip olmak bir zorunluluktur.

Aşağıdaki akış şeması, Sürüm Kontrolü ve CI için pratik bir yapıyı göstermektedir. Diyagramın neyi temsil ettiği konusunda size hızlı bir açıklama vermeye çalışacağız.

1. Bir geliştirici, sürüm kontrol sistemindeki değişikliklerini kontrol eder.
2. CI Sunucusu/Jenkins, en son yapıyı CI sanal alanına dağıtır ve test sınıflarını çalıştırır.
3. 2. adımdaki dağıtım başarılı olursa, değişiklikler QA dalında birleştirilir.
4. CI daha sonra KG şubesinden KG sanal alanına en son taahhüdü dağıtır.
5. QA, test hataları nedeniyle değişiklikleri reddederse, QA değişiklikleri temizleyene kadar 1'den 3'e kadar olan adımlar tekrar gerçekleştirilmelidir.
6. Değişiklikler KG'deki testi geçtikten sonra, değişiklikler Ana dalda birleştirilir.
7. Ana daldaki en son değişiklikler Ana sanal alana dağıtılır.

Kuruluşun ihtiyaçlarına bağlı olarak daha fazla şube eklemeyi seçebilirsiniz. Ancak yukarıdaki yapı, orta ila kurumsal düzeydeki geliştirme yapıları için gayet iyi çalışıyor.

Korumalı Alan Yönetimi

Kuruluşunuzun DevOps sürecinden en iyi şekilde yararlanmak için korumalı alan yapısını kurmak çok önemlidir. Daha derine inmeden önce, Salesforce'un bize sunduğu farklı korumalı alan türlerini tartışalım.

Korumalı alan, kişinin üretim meta verilerinin neredeyse tam bir kopyasıdır. Korumalı alanlar genellikle geliştirme, test etme, hazırlama ve eğitim amaçları için kullanılır. Dört tür sanal alan vardır ve bir sanal alan seçerken bir kişi dikkate alınmalıdır. Tam Kopya sanal alanları çok paraya mal olabilir!

Aşağıda, Salesforce tarafından farklı sanal alanlar için uygulanan sınırlara ilişkin tablo yer almaktadır.

Tablo 2: Limit Karşılaştırma

Korumalı alanlar arasındaki tek farkın fiyat olmadığını görebiliriz.

Geliştirici sanal alanının bir günlük yenileme süresi vardır, bu da onu geliştirme için uygun kılar, ancak yalnızca 200 MB veriyi barındırabilir ve üretim verisi içermez. Tam tersi olarak, tam kopya sanal alanları, üretim verilerinin tam bir kopyasına sahiptir; kayıt kimlikleri bile aynı. Bu, test etme ve hazırlama için harika olabilir, ancak 29 günlük yenileme süresi, tam kopya sanal alanında en son üretim meta verilerini ve verilerini almayı zorlaştırır.

Aşağıdaki tablo, sanal alanların seçilmesi için temel bir kural görevi görür:

Tablo 3: Korumalı Alan Seçimi için Kullanım Durumları

Orta ölçekli projeler için benimsenen tipik kuruluş yapısı aşağıdadır. Kurumsal düzeydeki müşteriler için kuruluş yapısı daha karmaşık hale gelir ancak genel olarak aşağıdaki modeli takip eder.

Salesforce geliştirmesi genellikle geliştirici sanal alanında (kırmızı) yapılır ve değişiklikler genellikle geliştirici uzmanı veya kısmi kopya sanal alanı olan entegrasyon sanal alanına (yeşil) taşınır. Ardından, birden çok tümleştirme sanal alanından yapılan değişiklikler, kısmi bir kopyalama sanal alanı olması gereken toplama sanal alanına (sarı) taşınır.

Kuruluşunuzun, entegrasyon testi ve yük testi yapılması gereken üçüncü taraf sistemle herhangi bir entegrasyonu varsa, yayından yayına değişmeyen kararlı bir veri setine sahip olmanız gerekir. Bu nedenle, bunun için tam bir kopya veya kısmi kopya sanal alanına sahip olmak daha iyidir.

Bu değişiklikler daha sonra testlerin gerçekleştirildiği entegrasyon testi sanal alanına taşınır. Ardından değişiklikler, tam bir kopya sanal alanı olması gereken hazırlama sanal alanına taşınır. Tüm test sınıfları dağıtımdan önce çalıştırılır. Dağıtımın herhangi bir sorun olmadan gerçekleşmesini sağlamak için bir dağıtım doğrulaması gerçekleştirilmelidir.

Bu süreç, değişikliklerin birden fazla test turundan ve bir çift gözden geçtiğinden emin olmamıza yardımcı olur. Değişiklikleri geliştirmek, test etmek ve dağıtmak için çok zaman gerektirmesi gibi ağır bir dezavantajla birlikte gelir.

Çok sık olarak, hata düzeltmeleri veya yamalar yapmak için acil bir ihtiyaç vardır. Bunları hızlı bir şekilde halletmek için, küçük yamaları doğrudan toplama sanal alanına itecek bir geliştirici sanal alanı tutmalısınız.

Daha önce de belirtildiği gibi, korumalı alan, üretim meta verilerinin neredeyse tam bir kopyasıdır, ancak tamamen değil. Bir sanal alanda devre dışı bırakılan bileşenlerin/özelliklerin resmi bir listesi vardır.

Korumalı alanı yenilerken göz önünde bulundurulması gereken başka bir şey, yalnızca üretim meta verilerini ve verilerini kopyalamasıdır. Meta verileri bir sanal alandan diğerine kopyalamanın veya herhangi bir meta veri yapılandırması (ücretsiz geliştirici kuruluşları gibi) olmadan boş bir sanal alan oluşturmanın hiçbir yolu yoktur. Bu bazen gerçek yaşam durumlarında bir meydan okuma haline gelir. Salesforce'un bu sorunu çözme planları vardır ve bu özellik yakında genel kullanıma sunulabilir.

Ek olarak, üretimde geliştirme veya test ekibinizin erişmemesi gerektiğini düşündüğünüz bazı hassas verileriniz varsa, tamamen veya kısmen kopyalanmış sanal alanlar için korumalı alan şablonları oluşturabilirsiniz.

Dağıtırken Neleri Dikkate Almalısınız?

Salesforce ekosisteminde uygulama yaşam döngüsü yönetiminin sektör uygulamalarını ele aldık. Meta veri ve korumalı alan yönetimi, dağıtım paketleri ve yükleri oluşturmada çok önemli bir rol oynar. Büyük ve karmaşık Salesforce uygulamaları için sürüm kontrolü, bir geri alma stratejisinin oluşturulmasına yardımcı olurken aynı zamanda meta veri değişikliklerinin izlenmesini sağlamaya yardımcı olur.

Korumalı alan yönetimi, büyük veya karmaşık projeler için kritik öneme sahiptir. Ancak Sandbox'lar, Salesforce ekosisteminde hem finansal kaynaklar hem de zaman açısından maliyetlidir. Korumalı alan yönetimi için bir strateji formüle etmek, sürüm yönetimi süreci için her zaman kritiktir.

Bir sonraki dağıtımınız sırasında aklınızda bulundurmanız gereken bazı ekstra noktalarla sizi baş başa bırakacağız:

1. Tek seferde yalnızca 10.000 dosya veya 39 MB'lık bir ZIP dosyası dağıtılabilir. Doğal olarak, yük çok büyükse, paketi birden çok parçaya bölmeniz ve ardından dağıtımı yapmanız gerekir.
2. Dağıtım, request timeout hatası nedeniyle başarısız oluyorsa, paketten nesneleri, özel alanları ve profilleri kaldırmayı deneyin. Bu bileşenlerin dağıtılması daha uzun sürer.
3. Bir alan türü değiştirilirse veya rol hiyerarşisinde değişiklikler varsa, verilerin yeniden hesaplanması nedeniyle tamamlanması biraz zaman alan uzun gecikmeler olabilir.
4. Salesforce, sistemde bir kullanıcı tarafından kullanılmakta olan tüm bileşenleri kilitler. Bu durumda dağıtmaya çalışırsak dağıtım başarısız olur.

Umuyoruz ki bu genel bakış, bir sonraki Salesforce sürümünüz sırasında size yardımcı olacaktır.

Kaynaklar