Kaynak dışa aktarılan projelerin taşınabilirlik testine ihtiyacı vardır

Kaynak kodu dışa aktarmak, dosyaları aldığınızı kanıtlar. Özgün yapay zeka uygulama oluşturucusu ortadan kalktıktan sonra projenin derlenebileceğini, başlayabileceğini, kullanıcıların kimliğini doğrulayabileceğini, üretim verilerini okuyabileceğini veya dağıtılabileceğini kanıtlamaz. Taşınabilirliği satış sözleşmesindeki bir onay kutusu değil, kabul testi olarak ele alın.

Yeterince üretilmiş uygulama devraldım; ilk bakışta temiz bir depoya güvenmem. Pahalı arızalar genellikle belirgin uygulama kodunun dışında gizlenir: sağlayıcı hizmetine yapılan çalışma zamanı isteği, başka birinin kiracısında kaydedilmiş kimlik doğrulama geri çağrısı, sürüm denetimine hiç girmemiş veritabanı politikası veya yalnızca yönetilen bir panoda bulunan dağıtım ayarı. Proje, ekibiniz dışa aktarımdan ve denetiminizdeki hesaplardaki belgelenmiş harici hizmetlerden çalışma davranışını yeniden üretebildiğinde taşınabilirdir.

Kaynak dışa aktarılan projeler yine de oluşturucuya bağlı olabilir

Kaynak dışa aktarılan proje, gerekli tüm derleme zamanı ve çalışma zamanı bağımlılıkları kullanılabilir, belgelenmiş, devredilebilir ve oluşturucu dışında kullanım için lisanslanmışsa bağımsız çalışır. Bu tanım, "depo derleniyor" ifadesinden daha katıdır. Kimlik, veri, zamanlanmış işler, sırlar, ağ kuralları ve kurtarma dahil olmak üzere boş bir makineden çalışan üretim sürümüne kadar olan yolu kapsar.

Üç ayrı iddia çoğu zaman birbirine karışır. Kaynak erişimi, dosyaları inceleyebileceğiniz anlamına gelir. Derleme bağımsızlığı, oluşturucuyu çağırmadan çıktı üretebilmeniz demektir. Çalışma zamanı bağımsızlığı ise bu çıktıların oluşturucu olmadan gerçek istekleri sunmayı sürdürmesidir. Sağlayıcı ilk iddiayı karşılayıp diğer ikisinde başarısız olabilir.

Bu ayrımın sözleşme açısından doğrudan sonucu vardır. Sözleşme "kaynak dışa aktarma" vaat ediyorsa, size React dizini, paket bildirimi ve README verilebilir; yine de özel bir SDK'ya veya barındırılan ağ geçidine ihtiyaç duyabilirsiniz. Bunun yerine operasyonel bir sonuç isteyin: yetkili bir mühendis, kabul edilen sürümü temiz bir ortamda müşterinin sahip olduğu hesapları kullanarak derleyip çalıştırabilmelidir.

Testten önce sınırı belirleyin. Yönetilen hizmetler otomatik olarak taşınabilirlik sorunu değildir. Ciddi uygulamaların çoğu buluta, ödeme işleyicisine, e-posta sağlayıcısına veya kimlik hizmetine bağlıdır. Sorun, bu bağımlılıkları bilerek seçip seçmediğiniz ve kendi sözleşmeniz altında taşıyıp değiştirebilmenizdir. Ayrı sözleşme yapılamayan gizli sağlayıcı hizmeti, bulut hesabınızdaki belgelenmiş PostgreSQL veritabanından farklıdır.

Her harici bileşen için dört alan içeren bir bağımlılık kaydı oluşturun: sahip, amaç, değiştirme yolu ve arıza davranışı. "Sahip", parolayı bilen kişi değil, hesabın yasal sahibidir. "Değiştirme yolu", geçiş yordamı, yeniden uygulayabileceğiniz bir arayüz veya hizmeti korumaya yönelik açık bir karar olabilir. "Arıza davranışı", hizmet kullanılamadığında kullanıcıların ne gördüğünü kaydeder. Satıcı bu alanları dolduramıyorsa, dışa aktarma riski fiyatlandıracak kadar iyi açıklanmamıştır.

En iyi ilk test sıradandır: oluşturucu hesabına erişimi kesin ve uygulamayı deneyin. Hazırlık kopyasında belirteçlerini iptal edin, bilinen alan adlarını ağ sınırında engelleyin ve neyin başarısız olduğunu görün. Her dosyayı okuyarak başlamayın. Çalışma zamanı kanıtı, eklenen yapılandırma ve derlenmiş paketlerin yaptığı çağrılar dahil kod incelemesinin kaçırdığı bağımlılıkları bulur.

Gerçek iş akışları çalışırken uygulamayı izleyin

Temsili iş akışları sırasında DNS'i, giden bağlantıları, tarayıcı isteklerini ve arka plan işlerini gözlemlediğinizde çalışma zamanı geri çağrıları kendini gösterir. Yüklenen bir ana sayfa çok az şey kanıtlar. Oturum açmayı, parola kurtarmayı, dosya yüklemeyi, aramayı, faturalama geçişlerini, e-posta teslimini, zamanlanmış görevleri, yönetici işlemlerini ve ürünün gerçekten sattığı yapay zeka destekli her özelliği deneyin.

Uygulamayı, giden trafiğin kaydedildiği yeni bir hazırlık ağında çalıştırın. Ona yalnızca bağımlılık kaydında listelenen hedefleri verin. Ortamınız izin veriyorsa listelenmeyen trafik için engelleme politikasıyla başlayın. Engellenen her istek bir sorudur: Gerekli mi, isteğe bağlı telemetri mi, güncelleme denetimi mi, yoksa belgelenmemiş denetim düzlemi çağrısı mı?

Bazı bağımlılıklar sunucunuza hiç uğramadığı için tarayıcı geliştirici araçları önemlidir. Depolamayı temizleyip yeni oturum kullandıktan sonra Ağ panelini inceleyin. İstek ana bilgisayarlarına, başarısız ön kontrol isteklerine, WebSocket bağlantılarına, yüklenen betiklere ve yönlendirmelere bakın. Sunucu deposu kendi kendine yeterli görünse bile ön yüz doğrudan oluşturucu API'sini çağırabilir. Hizmet çalışanları da eski davranışı koruyabilir; testi tekrarlamadan önce kayıtlarını kaldırın.

Unix benzeri kaynak ağacında bu arama kullanışlı bir ilk envanter verir:

grep -R -n -E 'https?:|wss?:|fetch[(]|axios|WebSocket|grpc|callback|webhook' .

path/to/file:line:matching text biçiminde çıktı bekleyin. Paket meta verilerindeki alan adı çalışma zamanı çağrısını kanıtlamadığından, üretilmiş kilit dosyalarını uygulama kodundan ayrı inceleyin. Tersine, temiz arama bağımsızlığı kanıtlamaz: ortam değişkenleri ana bilgisayarları oluşturabilir, DNS takma adları bunları gizleyebilir ve ikili bağımlılıklar kendi isteklerini yapabilir.

Sağlayıcı terimlerini, SDK içe aktarımlarını ve ortam değişkeni öneklerini ayrı geçişlerde arayın. Ardından paketlerin genel kayıt defterinden mi yoksa özel sağlayıcı kayıt defterinden mi çözüldüğünü görmek için kilit dosyalarını inceleyin. Önbellek başarısı burada sizi yanıltabilir. Yalıtılmış test ortamında dil paket önbelleklerini silin ve yalnızca belgelenmiş kayıt defteri kimlik bilgileriyle yeniden derleyin.

Zamanlayıcı sınırını geçecek kadar uzun süre arka plan davranışını izleyin. Kuyruk tüketicileri başarısız olurken, zamanlanmış raporlar dururken ve web kancası yeniden denemeleri birikirken web süreci sağlıklı görünebilir. Normal zamanlamalarını beklemek testi yavaşlatacaksa işleri elle tetikleyin. Her giden entegrasyon için hedefi, istek yöntemini, kimlik doğrulama türünü, yanıt sınıfını, yeniden deneme kuralını ve kullanıcıya görünen sonucu kaydedin.

"Bu geri çağrı yalnızca telemetri" sözünü, başarısızlığını test etmeden kabul etmeyin. Engelleyin ve iş akışını tekrar edin. İsteğe bağlı telemetri hızlı zaman aşımına uğramalı veya kullanıcının işlemini değiştirmeden başarısız olmalıdır. Günlük çağrılarının istek işlemi içinde kalıp zararsız analiz kesintisini başarısız kayda dönüştürdüğünü gördüm. Riski etiket değil, kod yolu belirler.

Özel SDK'ların kaldırma veya lisans yolu gerekir

Özel SDK, onu edinebiliyor, ona karşı derleyebiliyor, yasal olarak çalıştırabiliyor ve işletmenin tolere edebileceği sürede değiştirebiliyorsanız kabul edilebilir. Sarmalayıcı kaynağının dışa aktarmada bulunması, arkasındaki SDK, protokol, barındırılan uç nokta veya model için hak vermez.

Bağımlılıkları hem bildirimlerden hem kaynak içe aktarımlarından envantere alın. JavaScript için package.json ile kilit dosyasını inceleyin. Go için go.mod ve sağlama toplamlarını inceleyin. Flutter için pubspec.yaml ve kilit dosyasını inceleyin. Git depolarından, özel kayıt defterlerinden, yerel yollardan veya arşivlerden getirilen paketleri not edin. Oluşturucuya ait bileşenlerin saklanması için bunlar yaygın yerlerdir.

Şüpheli her paket için dört somut soruyu yanıtlayın:

1. Müşteriye ait yeni bir derleme aracısı tam sürümü indirebilir mi?
2. Lisans, oluşturucu sözleşmesi bittikten sonra üretim kullanımına izin veriyor mu?
3. Paket, müşterinin doğrudan sözleşme yapabileceği bir hizmeti çağırıyor mu?
4. Arayüz değiştirilecek kadar küçük mü ve bu arayüz test edilmiş mi?

Müşteriye ait kuruluşta oluşturulmuş kimlik bilgileriyle soğuk derleme yapın. Geliştiricinin tüm yapılandırma dizinini test makinesine kopyalamayın. Bu, önbelleğe alınmış paketleri, örtük kayıt defteri ayarlarını ve kişisel belirteçleri içeri alır, yani çalışmanın amacını bozar. Doğru derleme yordamı belgelenmiş araç zinciri sürümüyle başlar ve her ek kimlik bilgisini ayrı ayrı bildirir.

Araç zinciri destekliyorsa yazılım malzeme listesi oluşturun, ancak bu belgeyi taşınabilirlik kararıyla karıştırmayın. SBOM bileşenleri listeler; uzaktaki hesabı kimin denetlediğini veya paketin dışarıya çağrı yapıp yapmadığını nadiren söyler. Depoda bildirilenleri, derlenmiş çıktının içerdikleriyle karşılaştırmak için kullanın.

Özel istemci dar bir bağdaştırıcının arkasındaysa, şimdi bağdaştırıcıya karşı bir sözleşme testi yazın. Ona bilinen bir istek verin, normalize edilmiş yanıtı doğrulayın ve ağ uç noktası engellenmişken aynı testi çalıştırın. Başarısızlık açık ve sınırlı olmalıdır. Özel çağrılar görünüm bileşenlerinde, rota işleyicilerinde ve veri modellerinde her yere yayılmışsa, imzalamadan önce yeniden düzenleme maliyetini fiyatlandırın. Sorun SDK'nın satır sayısıyla değil, çağrı noktası sayısı ve anlamsal bağla büyür.

Ekipler çoğu zaman satın alma öncesinde her özel bağımlılığı değiştirmeyi önerir. Bu güvenli görünür, ancak alıcının tutmak istediği hizmetler için haftalar harcatabilir. Daha iyi kural şudur: Kullanılamayan veya sözleşme yapılamayan bağımlılıkları kaldırın, kabul ettiklerinizi yalıtın ve kalanlara geçiş maliyeti ekleyin. Taşınabilirlik, sıfır harici hizmete sahip uygulama değil, seçenekler üzerindeki denetimdir.

Kimlik doğrulama kaynak ağacından fazlasına bağlıdır

Kimlik doğrulama ancak müşteri kimlik kiracısını, yönlendirme kayıtlarını, imzalama anahtarlarını, kullanıcı tanımlayıcılarını, e-posta şablonlarını ve kurtarma sürecini denetlediğinde temiz taşınır. Uygulama kodu genellikle bu sistemin yalnızca bir dilimini yakalar.

Oturum açma yolunu gerçek atlamalarla çizmeye başlayın. Tarayıcı uygulamaya ulaşır, uygulama kimlik sağlayıcısına yönlendirir, sağlayıcı kayıtlı geri çağrıya döner ve arka uç kimlik bilgilerini değiştirir veya doğrular. Her atlamada sahip ve yapılandırma konumunu kaydedin. Herhangi bir konsola yalnızca oluşturucunun kuruluşu üzerinden erişilebiliyorsa, kabul öncesinde devir veya değiştirme isteyin.

Yönetilen kimlik doğrulama özellikle zor bir veri sorunu yaratır. Uygulamanın kullanıcı tablosu e-posta adresi veya dahili kalıcı kimlik yerine sağlayıcıya özgü bir özne saklayabilir. Yeni kimlik kiracısı farklı özneler veriyorsa satırları dışa aktarmak işe yaramaz. Hesap eşleştirmesini, yinelenenleri ele almayı, parolalı kullanıcıları, sosyal oturum açan kullanıcıları, çok faktörlü kaydı, kilitli hesapları ve e-posta adresi değişmiş kullanıcıları test edin.

OpenID Connect, sub talebini verenin kapsamı içinde yerel olarak benzersiz ve asla yeniden atanmayan tanımlayıcı olarak tanımlar. Veren önemlidir. sub değerini tek başına küresel olarak taşınabilir saymak, kiracı değişikliğinden sonra yanlış uygulama kaydını bağlayabilir. Verenle özneyi birlikte saklayın ve karşılaştırın, ardından geçiş için açık bir eşleme tasarlayın.

Testinizde en az dört hesap gerekir: normal kullanıcı, yönetici, devre dışı kullanıcı ve ikinci kimlik doğrulama faktörü olan kullanıcı. Kimlik yapılandırmasını müşteriye ait kiracıya taşıyın veya yeniden oluşturun, hazırlık veritabanı kopyasını geri yükleyin ve başarılı oturum açmanın yanı sıra erişim reddini doğrulayın. Oturum kapatmayı, belirteç yenilemeyi, parola sıfırlamayı, davet kabulünü ve oturum bitişini de test edin. Ekipler sorunsuz oturum açma yolunu hatırlar, bozuk kurtarmayı ise geçişten sonra fark eder.

Depoda yönlendirme URI'lerini, istemci kimliklerini, veren adlarını, çerez alan adlarını, hedef kitle değerlerini ve imzalama anahtarı başvurularını arayın. Sırları depodan uzak tutun; ancak adlarını, sahiplerini, oluşturma adımlarını, döndürme adımlarını ve gereken biçimleri dağıtım belgelerinde saklayın. Örnek ortam dosyası canlı değer içermeden sözleşmeyi tanımlamalıdır:

AUTH_ISSUER=
AUTH_CLIENT_ID=
AUTH_CLIENT_SECRET=
AUTH_CALLBACK_ORIGIN=
SESSION_SIGNING_KEY=

Geçiş "sonra" yapılabilir diye ortak oluşturucu kiracısını kalıcı düzenleme olarak kabul etmeyin. Kimlik geçişleri her etkin kullanıcıya ve her yetkilendirme varsayımına dokunur. İmzalamadan önce denetimi devredin veya değiştirmeyi anlaşmanın fiyatlandırılmış, test edilmiş koşulu yapın.

Veritabanı taşınabilirliği davranışı ve operasyonları da kapsar

Şemalar, eklentiler, satır düzeyi politikalar, tetikleyiciler, nesne depolama, kuyruklar, yedekler ve bağlantı kuralları dışında yaşıyorsa veritabanı dökümü yetersizdir. Veritabanı taşınabilirliği, verileri geri yükleyip onları koruyan ve değiştiren davranışı yeniden üretebilmeniz demektir.

Belgelenmiş ana sürümde, müşteriye ait boş PostgreSQL örneğiyle başlayın. Depo geçişlerini sırayla uygulayın. Projede geçiş yoksa ve sağlayıcının oluşturduğu şema dökümünü içe aktarmak gerekiyorsa bunu kusur olarak kaydedin. Döküm bugünkü durumu yakalayabilir, ancak sonraki sürümün bu durumu güvenle nasıl değiştireceğini açıklamaz.

Geri yüklenen şemayı üretim veya hazırlık ortamıyla karşılaştırın. Tabloları, sütunları, türleri, kısıtları, dizinleri, sıraları, görünümleri, işlevleri, tetikleyicileri, etkin eklentileri, rolleri, izinleri ve satır düzeyi güvenlik politikalarını denetleyin. Birçok geçiş aracı rolleri ve sağlayıcı düzeyindeki ayarları atlar. Geri yüklenen rolün sıra veya işlev izni olmadığı için yönetim işleri başarısız olurken uygulama temel okuma testlerini geçebilir.

Ardından denetimli bir gidiş dönüşle veri yolunu doğrulayın:

1. Genel uygulama iş akışıyla bir kayıt oluşturun.
2. Paylaşımın beklendiği yerde, ikinci yetkili kullanıcıyla okuyun.
3. Yetkisiz kullanıcının onu okuyamadığını veya değiştiremediğini doğrulayın.
4. Uygulama üzerinden güncelleyin ve silin.
5. Veritabanını başka temiz bir örneğe geri yükleyin ve okumaları tekrarlayın.

Bu sıra uygulama kodunu, yetkilendirme politikasını, üretilen değerleri ve kurtarılabilirliği birlikte test eder. Doğrudan SQL satır sayıları bu davranışları kapsayamaz.

Satırlar yüklenen dosyalara işaret ediyorsa nesne depolamayı veritabanı sınırının parçası sayın. Kovaları, nesne meta verilerini, erişim kurallarını, yaşam döngüsü kurallarını ve URL oluşturma ayarlarını dışa aktarın. Temel dosyalar oluşturucuya ait kovada kalırken nesne anahtarlarıyla dolu geri yüklenmiş veritabanı işe yaramaz. Aynı uyarı arama dizinleri ve vektör depoları için de geçerlidir: onları taşıyıp taşımayacağınıza veya yeniden derleyip derlemeyeceğinize karar verin ve yeniden derleme yordamını kanıtlayın.

Başarıyı veya başarısızlığı tek küçük dökümden ölçmeyin. Uzun metinler, null değerler, ASCII dışı karakterler, büyük nesneler, yaz saati uygulaması değişiklikleri çevresindeki zaman damgaları ve temsili ilişkiler içeren hazırlık boyutunda bir kopya kullanın. Yapay kıyaslamalara ihtiyacınız yok. Aktarımın izin verilen kesinti süresi içinde tamamlandığına ve uygulamanın sonrasında doğru davrandığına dair kanıta ihtiyacınız var.

Yedekleme iddiaları geri yükleme gerektirir. Yedekleri kimin zamanladığını, kopyaların nerede bulunduğunu, onları kimin çözebildiğini, saklamanın nasıl işlediğini ve başarısız yedeği nasıl tespit ettiğinizi belirleyin. Birini yazılı talimatlarla yalıtılmış hesaba geri yükleyin. Geri yükle düğmesine yalnızca oluşturucu basabiliyorsa, bağımsız kurtarma planı değil hizmet özelliğiniz vardır.

Eksik CI işlem hattı, eksik ürün bilgisidir

Tekrarlanabilir sürekli entegrasyon olmadan dışa aktarılan depo, alıcıyı araç sürümlerini, derleme sırasını, testleri, çıktı paketlemeyi, veritabanı geçiş zamanlamasını ve yayın kapılarını yeniden keşfetmeye bırakır. Satıcının iç işlem hattı aynen devredilemiyor olsa bile bu bilgi teslimatın parçasıdır.

İşlem hattı tanımlarını, konteyner derleme dosyalarını, araç sürümü dosyalarını, test komutlarını, lint kurallarını, geçiş komutlarını ve altyapı tanımlarını arayın. Sonra bunları gerçek dağıtım günlüğüyle karşılaştırın. Belgeler çoğu zaman basit web derlemesini anlatır, ancak yönetilen platform sessizce yapılandırma üretebilir, sunucu bileşeni ekleyebilir, mobil paket derleyebilir veya veritabanı geçişleri çalıştırabilir.

Müşteriye ait CI hesabında asgari işlem hattını yeniden kurun. Sabitlenmiş revizyonu almalı, bildirilmiş araç zincirini kurmalı, bağımlılıkları getirmeli, testleri çalıştırmalı, değişmez çıktılar üretmeli ve çıktı kimliğini kaydetmelidir. Test sırasında dağıtım elle kalabilir, ancak hazırlık ortamına ulaşan çıktı işlem hattının ürettiği çıktı olmalıdır.

Kısa kabul günlüğü şu biçimi kullanabilir:

revision: 4f2c9ab
toolchain: declared versions loaded
dependencies: cold install passed
tests: unit and integration passed
artifacts: web, server, mobile
migrations: dry run passed
staging: health and workflow checks passed

Değerler değişir, ancak her satır kişinin hatırlaması değil, makine çıktısı veya bağlantılı dahili kayıt gerektirir. Günlüğü kabul kanıtlarıyla birlikte saklayın.

İhtiyacınız yoksa satıcının gizli dağıtım düzeneklerini istemeyin. Sonucu yeniden üretmeye yetecek talimatı ve yapılandırmayı isteyin. Taşınabilir işlem hattı, aynı gerekli aşamaları gerçekleştirdiği ve yayın denetimlerini zayıflatmadığı sürece farklı CI ürünü hedefleyebilir.

Mobil uygulamalar imzalama varlıkları, paket tanımlayıcıları, mağaza hesapları ve anlık bildirim kimlik bilgileri ekler. Kaynak derlemesi bunlar olmadan emülatörde çalışabildiği için gözden kaçmaları kolaydır. Dağıtım hesaplarının müşteriye ait olduğunu doğrulayın ve sertifika döndürmeyi belgeleyin. Sunucu ve web uygulamalarında alan adı doğrulamasını, TLS sertifikası düzenlenmesini, DNS değişikliklerini ve önbellek geçersizleştirmeyi yayın çalışmasına dahil edin.

İşlem hattı testi, sağlanan kaydın yeniden derlenmesiyle değil, bir değişiklikle biter. Zararsız görünür düzenleme yapın, geri alınabilir veritabanı geçişi ekleyin, derleyin, hazırlık ortamına dağıtın, doğrulayın ve geri alma işlemini uygulayın. Bu, bir kez depoya eklenen fakat yeniden üretilemeyen çıktıları yakalar.

Dil araç zincirinin yanı sıra derlemede kullanılan işletim sistemi paketlerini de sabitleyin. Yerel modüller, oluşturucunun imajında tesadüfen bulunan kitaplıklara göre derlenebilir. Yeni çalıştırıcı daha uygulama testleri başlamadan başarısız olur veya daha kötüsü, farklı davranan çıktı üretir. Paket adlarını ve sürümlerini konteyner tanımında ya da eşdeğer makine tarafından okunabilir derleme açıklamasında yakalayın.

İşlem hattının müşteri denetimindeki depodan sırları alabileceğini kanıtlarken sırları CI günlüklerinden uzak tutun. Test, kısa ömürlü hazırlık kimlik bilgisi oluşturmalı, bunu belgelenmiş mekanizmayla eklemeli ve kaynak düzenlemeden döndürebilmelidir. Sırın destek personeli tarafından sağlayıcı panosuna yapıştırılması gerekiyorsa, kurulum notlarında gizlemek yerine bu bağımlılığı kaydedin.

Barındırma varsayımları temiz ortamda dağıtımda ortaya çıkar

Temiz ortamda dağıtım, oluşturucuyu tanımayan bir ekip yalnızca dışa aktarma, bildirilmiş hizmetler ve yazılı talimatlarla sistemi müşteriye ait ortamda başlatabildiğinde taşınabilirliği kanıtlar. Bunu sözleşme kabulünden önce, zaman sınırı ve sorun günlüğüyle çalıştırın.

Hedeflenen işletim modeline uyan ortamı seçin. Yönetilen platformdan ham sanal makinelere geçmek ilgisiz işler yaratır ve taşınabilir projenin bozuk görünmesine yol açabilir. Konteynerler, PostgreSQL, nesne depolama, zamanlanmış işler, sırlar ve yük dengeleme gibi gereken temel öğeleri eşleştirin, ancak belgelenmemiş sağlayıcı sihrini yeniden yaratmayın.

Uygulamayı yazılabilir yerel diskler, sabit portlar, yapışkan oturumlar, güvenilir vekil üst bilgileri, bölge adları, eklenmiş ana bilgisayar adları ve platforma özgü ortam değişkenleri hakkındaki varsayımlar açısından inceleyin. Twelve-Factor App, yapılandırmayı ortamda tutmayı ve destek hizmetlerini bağlı kaynaklar olarak ele almayı önerir. Bu fikirler hâlâ yararlıdır, ancak ortam değişkenleri tek başına sahipliği, biçimleri veya oluşturmayı belgelemez. Her değişkeni operasyon kaydıyla eşleştirin.

Sağlık denetimleri doğrudan test edilmelidir. Geçişler bitmeden veya gereken bağımlılıklar bağlanmadan başarı döndüren süreç, düzenleyici arkasında yeniden başlatma döngüsüne girebilir. Barındırma sistemi destekliyorsa canlılık ile hazır olma denetimlerini ayırın. Veritabanını, nesne deposunu ve kuyruğu tek tek durdurun; sonra durum kodlarını, günlükleri, yeniden deneme davranışını ve hizmet döndüğündeki kurtarmayı gözlemleyin.

Uygulamanın birden fazla örneği nasıl ele aldığını doğrulayın. Bellek içi oturumlar, yerel yükleme dizinleri ve süreç yerelindeki iş kilitleri, tek yönetilen örnekte çalışır ancak ölçeklemeden sonra başarısız olur. İki örnek başlatın, aynı kullanıcının isteklerini ikisinden de gönderin ve eşzamanlı iş çalışanları çalıştırın. Oturumların kalıcı olduğunu, dosyaların erişilebilir kaldığını ve zamanlanmış görevin idempotent tasarlanmadıkça iki kez çalışmadığını denetleyin.

Kapanışı da başlangıç kadar dikkatle gözlemleyin. İstekler ve arka plan işleri etkin durumdayken sonlandırma sinyali gönderin. Süreç yeni iş kabul etmeyi bırakmalı, alınan işleri bitirmeli veya güvenle geri vermeli, bağlantıları kapatmalı ve ana bilgisayarın tanıdığı ek süre içinde çıkmalıdır. Yönetilen oluşturucu, yeni barındırıcınızda olmayan uzun zaman aşımları veya yeniden denemelerle ani kapanışları gizlemiş olabilir.

Günlükler ve ölçümler de barındırma varsayımları taşır. Uygulamanın yapılandırılmış olayları belgelenmiş hedefe yazdığını, gerektiğinde sırları ve kişisel verileri kaldırdığını ve başarısız iş akışını teşhis edecek yeterli bilgiyi sunduğunu doğrulayın. Standart çıktı veya müşteri denetimindeki başka bir hedef gerekli kanıtı koruyorsa özel pano isteğe bağlıdır.

Bölge ve veri konumu iddiaları yapılandırma kanıtı gerektirir. Uygulamanın, veritabanının, yedeklerin, günlüklerin ve nesne depolamanın nerede çalıştığını, ayrıca hangi harici hizmetlerin veri aldığını kaydedin. Web süreci için bölge seçici, kimlik doğrulama veya analiz veriyi başka yere gönderiyorsa veriyi ülkede tutmaz. Sözleşme bu konumlardaki değişiklikleri kimin onayladığını belirtmelidir.

Koder.ai kaynak dışa aktarmayı, dağıtımı ve barındırmayı, özel alan adlarını, anlık görüntüleri ve geri almayı destekler. Dışa aktarılan Koder.ai projesini bağımsız çalışma için değerlendiriyorsanız aynı temiz ortam standardını kullanın: dışa aktarılan React, PostgreSQL ile Go veya Flutter bileşenlerini sahip olmak istediğiniz ortamda test edin ve korumayı seçtiğiniz her hizmeti belgeleyin.

Geçti ve kaldı koşullarını sözleşmeye koyun

Sözleşme, taşınabilirliği gözlemlenen davranış olarak tanımlamalı, kabul ortamını listelemeli, düzeltme sorumluluğunu atamalı ve son ödeme veya bağımlı kalma öncesinde arızaları gidermeye yetecek süreyi korumalıdır. Belirsiz sahiplik dili, kimsenin dağıtamayacağı uygulamayı kurtarmaz.

"Kaynak kod" başlıklı paragrafa güvenmek yerine kabul matrisi ekleyin. Her satırda yetenek, test yordamı, beklenen sonuç, kanıt, sorumlu taraf ve önem derecesi yer almalıdır. Soğuk derlemeyi, çalışma zamanı ağ çağrılarını, kimlik devrini, veritabanı geri yüklemeyi, dosya depolamayı, arka plan işlerini, CI'ı, temiz dağıtımı, izlemeyi, yedek geri yüklemeyi, küçük değişikliği ve geri almayı kapsayın.

Üçüncü tarafın gözlemleyebileceği geçme ölçütleri kullanın. "Kritik özel bağımlılık yok" tartışmaya davet eder. "Hazırlık uygulaması, oluşturucuya ait tüm kimlik bilgileri iptal edilmiş ve oluşturucu alan adları engellenmişken A'dan F'ye iş akışlarını tamamlar" ifadesi test edilebilir. Ekibin onaylanmış yönetilen hizmeti başarısızlık sanmaması için izin verilen bağımlılıkları adı ve hesap sahibiyle tanımlayın.

Kaynağın ve operasyon malzemelerinin sabitlenmiş revizyonda teslimini isteyin: kilit dosyaları, geçişler, derleme tanımları, mevcutsa altyapı yapılandırması, ortam değişkeni kataloğu, bağımlılık kaydı, veri dışa aktarımı, kimlik geçiş planı, çalışma kılavuzları, lisans bildirimleri ve müşteriye ait imzalama veya dağıtım varlıkları. Hariç tutulanları açıkça kaydedin. Sessizlik kabul anlamına gelmemelidir.

Önem derecesini iş etkisine göre belirleyin. Eksik isteğe bağlı analiz olayı, oturum açma kesintisiyle aynı değildir. Kullanışlı şema, derlemeyi veya temel iş akışlarını engelleyen bloklayıcıları, önemli yeteneği veya kurtarma yolunu kaldıran büyük kusurları ve belgelenmiş geçici çözümü olan küçük kusurları ayırır. Evrensel takvim uydurmadan kabul ve düzeltme tarihlerini bu düzeylere bağlayın.

Test verisini ve test operatörünü de tanımlayın. Satıcılar bazen taşınabilirliği boş veritabanı ve normal yetkilendirmeyi atlayan yönetici hesabıyla gösterir. Müşteri personelinin belgelenmiş yordamı uygulamasıyla, temsili kullanıcıları, rolleri, dosyaları ve arka plan işlerini isteyin. Sırları sentetik tutun, ancak ilişkileri ve uç durumları gerçekçi tutun.

Maliyetler kanıt paketine dahildir. Dışa aktarılan sürümü çalıştırmak için gereken ayrı faturalandırılan hizmetleri ve satıcının belirttiği asgari katmanı, veri çıkış ücretini veya özel kayıt defteri aboneliğini kaydedin. Testin gelecekteki her faturayı tahmin etmesi gerekmez. Sözde bağımsız dışa aktarmanın, imzadan sonra kaçınılmaz sağlayıcı sözleşmesini ortaya çıkarmasını engellemelidir.

Hemen devredilemeyen hizmetler için iş birliği yükümlülüklerini ekleyin. Satıcının anahtarları döndürmesi, kimlik dışa aktarımını onaylaması, alan adını taşıması veya son veri anlık görüntüsünü sağlaması gerekebilir. İşlemi ve sorumlu kişiyi adlandırın. "Makul yardım", üretim kapalıyken uygulaması zordur.

Düzeltmeden sonra ve son dışa aktarmadan sonra testleri tekrarlama hakkını koruyun. Üretilmiş projeler hızla değişir; geçen ayın revizyonunda kanıtlanan düzeltme, dün eklenen yeni bağımlılıklar hakkında bir şey söylemez. Test edilen kaydı ve çıktı karmalarını kabul kaydına sabitleyin.

Emanet hükmünün bu çalışmanın yerini almasına izin vermeyin. Emanet, tetikleyici olaydan sonra dosyaları teslim edebilir; ancak güncel derleme talimatları, kimlik bilgisi sahipliği ve test edilmiş kurtarma yolları olmayan dosyalar fayda sağlamak için çok geç gelebilir. Operasyonel bağımsızlık, iki taraf hâlâ iş birliği yapabilirken mevcut olmalıdır.

İkinci ekip, kabul edilen sürümü özgün oluşturucunun ayrıcalıklı yardımı olmadan derleyebildiğinde, çalıştırabildiğinde, değiştirebildiğinde, dağıtabildiğinde ve kurtarabildiğinde imzalayın. Bunun altındaki her şey, çözülmemiş geçiş projesi eklenmiş kaynak sahipliğidir ve sözleşme fiyatı bu işi yansıtmalıdır.