30 günde kurumsal vibe coding pilotu

Kurumsal bir vibe coding pilotu, ekibin üretime benzeyen koşullarda platformu çalıştırabildiğini, inceleyebildiğini, kurtarabildiğini ve terk edebildiğini kanıtlamalıdır. Çekici bir uygulamayı hızla üretmek faydalıdır, ancak değerlendirmedeki en düşük maliyetli soruya yanıt verir.

Sözleşme; kaynak dışa aktarma, erişim denetimi, veri konumu, dağıtım, geri alma, denetim kayıtları ve geliştirici devri için kaydedilmiş geçer veya kalır sonuçlarına bağlı olmalıdır. Satıcı testi kontrol ediyorsa, belirsiz sonuçları açıklamalarla geçiştiriyorsa ya da son alıştırma sırasında eksik adımları kendisi sağlıyorsa, pilot kurumsal hazırlığı değil satıcı desteğini ölçmüştür.

Pilot, geliştirme hızının yanı sıra çıkış maliyetini de ölçer

Pilot başlamadan önce kabul planı sabitlenmelidir. Aksi hâlde her zor sonuç, daha fazla süre isteğine, daha dar bir yoruma ya da sonraki sürümün sorunu çözeceği vaadine dönüşür.

Tamamlanabilecek kadar küçük, operasyonel riski açığa çıkaracak kadar karmaşık tek bir referans uygulaması seçin. Birden fazla kullanıcı rolü, kiracı sınırları, kalıcı kayıtlar, dosya işlemleri, harici bir hizmet, arka plan işleri, sırlar ve en az bir veritabanı geçişi içermelidir. Tanıtım sitesi, kurumsal uygulama platformu hakkında neredeyse hiçbir şey kanıtlamaz.

Her testi, platform dışında saklanan bir kanıt dosyasına kaydedin. Basit bir yapı sonucu incelenebilir tutar:

pilot:
  application: claims-intake-reference
  revision: 8f21c6a
  test_owner: enterprise-architecture
  vendor_observer: true
controls:
  source_export:
    result: pending
    evidence: []
    blocker_if_failed: true
  access_control:
    result: pending
    evidence: []
    blocker_if_failed: true
  data_location:
    result: pending
    evidence: []
    blocker_if_failed: true
exceptions:
  owner: procurement
  expires: 2026-09-30
  compensating_control: null

Revizyon, test edilen uygulamanın tam olarak hangisi olduğunu gösterir. Her kanıt girdisi, dışa aktarılan arşiv, terminal dökümü, günlük dosyası, kimlik yapılandırması, kurtarma süresi ya da imzalı satıcı yanıtı gibi ekibinizin denetlediği materyallere işaret etmelidir. Ekran görüntüleri sonucu destekleyebilir, ancak istekleri, yanıt kodlarını, yapılandırma geçmişini ve çevredeki durumu göstermedikleri için tek başlarına nadiren kanıt olur.

Kapıları tercihlerden ayırın. Taşınabilirlik, kiracı yalıtımı, kurtarılabilirlik, veri konumu ve denetim bütünlüğü genellikle kapı kategorisine girer. Düzenleyici kullanım kolaylığı ve üretim hızı benimsemeyi etkileyebilir, ancak bu alanlardaki yüksek puan başarısız bir yalıtım testini telafi edemez. Tüm sonuçları tek, neşeli bir puanda ortalamak yaygın bir satın alma hatasıdır. Bu yaklaşım, on yüzeysel geçişin bir tehlikeli başarısızlığı gizlemesine izin verir.

Her denetime bir kurumsal sorumlu ve başarısızlık kararı verebilecek bir kişi atayın. Satıcı gözlem yapabilir ve olgusal hataları düzeltebilir, ancak kendi işini puanlamamalıdır. Sağladığı her yardımı kaydedin. Satıcı çalışanları dışa aktarmayı onarıyor, politika değiştiriyor ya da geri almayı yürütüyorsa, testi geçer saymadan önce onlarsız tekrarlayın.

Ekip kanıtları sürekli test ettiğinde 30 günlük takvim işler. Kapsamı sabitleyin ve referans uygulamayı erken oluşturun. Sonra yıkıcı testler, temiz ortamda yeniden kurulumlar, kimlik hataları, geri yükleme alıştırmaları ve devir için önemli zaman ayırın. 28. güne kadar geliştiren ekipler, kapanış toplantısını çoğunlukla hiç test etmedikleri özellikleri konuşarak geçirir.

Kaynak dışa aktarımı bağımsız bir derleme üretmelidir

Kaynak dışa aktarımı, kurum uygulamayı platform erişimi olmadan temiz bir ortamda derleyebildiğinde, test edebildiğinde, çalıştırabildiğinde ve değiştirebildiğinde geçer. Kodla dolu bir dizine sahip olmak, taşınabilir bir uygulamaya sahip olmakla aynı şey değildir.

Sabitlenmiş bir revizyonu dışa aktarın, sağlama toplamını kaydedin ve kurumsal denetimdeki yeni bir depoya taşıyın. Satıcı çerezleri, komut kimlik bilgileri, paket önbelleği, üretilmiş dosyalar veya gizli ortam değişkenleri bulunmayan temiz bir makine ya da geçici derleme çalışanı kullanın. Kodu devralan geliştiricide yalnızca dışa aktarma çıktısı ve dokümantasyonu bulunmalıdır.

Toplantıda verilen komutları değil, deponun belirttiği komutları çalıştırın. React ve Go uygulaması için döküm şu yapıda olabilir:

$ npm ci
added 428 packages, and audited 429 packages
$ npm test
Test Suites: 18 passed, 18 total
$ go test ./...
ok   example/api/auth
ok   example/api/orders
$ go build ./cmd/server
$ ./server
configuration error: DATABASE_URL is required

Son hata, utanç verici değil faydalı bir geçiştir. Programın gizlice satıcı hizmetine ulaşmak yerine eksik bağımlılığı adlandırdığını kanıtlar. Belgelenmiş yapılandırma sağlandıktan sonra ekip uygulamayı başlatmalı, geçişleri uygulamalı, kullanıcı oluşturmalı, bir test ikamesi üzerinden harici entegrasyonu çalıştırmalı ve otomatik testleri yürütmelidir.

Twelve-Factor App, bir uygulamanın tek bir kod tabanını sürüm denetiminde izlemesi ve bağımlılıklarını açıkça belirtmesi gerektiğini söyler. Bu kurallar hâlâ yararlıdır, ancak taşınabilirlik konusunda hüküm vermez. Üretilmiş uygulamalar genel bağımlılıkları belirtebilirken tescilli kimlik aracılarına, dağıtım meta verilerine, barındırılan işlevlere, derleme eklentilerine veya çalışma zamanı uç noktalarına bağımlı kalabilir. Testiniz bu bağımlılıkları bulmalı ve hangilerinin değiştirilebileceğini sınıflandırmalıdır.

Dışa aktarılan çıktıda kaynak haritaları, üretilmiş istemciler, geçiş dosyaları, test sabitleri, derleme tanımları, lisans bildirimleri, altyapı yapılandırması ve bağımlılık kilit dosyası arayın. Sabit kodlanmış hizmet adreslerini, anlaşılmaz ikili bileşenleri, kopyalanmış sırları ve yalnızca platform içinde çözümlenen içe aktarımları tarayın. Ekip ayrıca, ilişki sona erdikten sonra hangi yapıtları kullanma konusunda sözleşmeye dayalı hakkı olduğunu bilmelidir. Teknik olarak sahip olmak, eksik hakları gideremez.

Veritabanı taşınabilirliği bu kapı içinde ayrı bir kontrolü hak eder. PostgreSQL belgeleri, pg_dump komutunun tek bir veritabanını dışa aktardığını ve tutarlı bir anlık görüntü ürettiğini, ancak roller gibi küme genelindeki nesneleri dışa aktarmadığını açıklar. Yalnızca uygulama veritabanını geri yükleyen ekip, sahiplik ve izin varsayımlarının kaybolduğunu fark edebilir. Şema oluşturmayı, başlangıç verilerini, rolleri yeniden oluşturmayı, eklentileri ve kurumsal denetimdeki PostgreSQL örneğine geri yüklemeyi test edin.

Yazılı talimatlarla, platforma yabancı bir geliştirici dışa aktarma çıktısından çalışan sistemi yeniden üretebiliyor ve her satıcı çalışma zamanı bağımlılığını değiştirebiliyor ya da kabul edilmiş ikamesini belirleyebiliyorsa geçin. Dosyalar eksikse, derlemeler özel hizmetleri çağırıyorsa, şema geçmişi veritabanını yeniden oluşturamıyorsa, arşivde sırlar görünüyorsa veya satıcı müdahale etmek zorundaysa kalın. Yol haritasındaki gelecekteki bir dışa aktarma özelliği sonucu değiştirmez.

Erişim denetimi doğrudan isteklerde de ayakta kalmalıdır

Erişim denetimi, kullanıcı üretilmiş arayüzü atlasa bile sunucu her yetkisiz işlemi reddettiğinde geçer. Düğmeyi, rotayı veya menü öğesini gizlemek yetkilendirmeyi değil, sunumu test eder.

Uygulamayı üretmeden önce rolleri ve kaynakları tanımlayın. Kiracı sınırlarını ve hassas eylemleri içeren küçük bir izin matrisi kullanın:

Her reddi tarayıcıdan ve API'yi doğrudan çağırarak deneyin. Nesne tanımlayıcılarını, kiracı tanımlayıcılarını, sorgu filtrelerini ve istek gövdelerini değiştirin. Ekipler tek kayıt yolunu sıkça koruyup dışa aktarma, arama, ek dosya ve toplu güncelleme rotalarını unuttuğu için toplu uç noktaları ayrıca deneyin. İstemci değişikliği tüm görsel kısıtlamaları kaldırdıktan sonra sunucu zorlamasını doğrulayın.

OWASP Application Security Verification Standard 4.0, erişim denetimi doğrulamasını güvenilir hizmet katmanlarına yerleştirir ve erişimin varsayılan olarak reddedilmesini bekler. Bu öneri, şık bir arayüz yanlış güven yaratabildiği için üretilmiş sistemlerde daha da önemlidir. Kısıtlı kullanıcının düzenleme düğmesi olmadığı için rol demosunu kabul eden, ardından aynı kullanıcının düzenleme isteğini elle gönderebildiğini keşfeden ekipler gördüm.

Kimlik doğrulama ve yetkilendirme için ayrı kararlar verin. Kimlik doğrulama, kimin kimlik bilgisi sunduğunu belirler. Yetkilendirme ise bu kimliğin şimdi, bu nesne üzerinde, bu işlemi yapıp yapamayacağına karar verir. Tek oturum açma geçebilirken nesne yetkilendirmesi tüm kiracılarda başarısız olabilir.

Kurumsal kimlik sağlayıcısını bağlayın ve işe başlama, görev değişikliği, işten ayrılma durumlarını test edin. Kullanıcı oluşturun, kullanıcının grubunu değiştirin, yüksek ayrıcalıklı rolü kaldırın, hesabı devre dışı bırakın ve etkin oturumları iptal edin. Her değişikliğin uygulamayı etkilemesinin ne kadar sürdüğünü ölçün. Alıştırmayı sıradan uygulama kullanıcılarıyla sınırlamak yerine acil durum yerel hesaplarını, hizmet kimliklerini, API kimlik bilgilerini ve platform yöneticilerini test edin.

OpenID Connect Core, sub talebini veren içinde yerel olarak benzersiz ve asla yeniden atanmayan bir tanımlayıcı olarak tanımlar. Bu kalıcı tanımlayıcıyı, okunabilir oturum açma adıyla birlikte saklayın ve denetleyin. E-posta adresleri ve görünen adlar değişir. Yalnızca bunları kullanmak sahiplik geçmişini bozabilir veya hesap yeniden kullanıldıktan sonra iki ayrı kişinin aynı kişi gibi görünmesine yol açabilir.

Daha düşük ayrıcalıklı bir kullanıcı kiracı sınırını aşabiliyorsa, yönetici erişimi kaydedilmiş onayı atlıyorsa, kaldırılan ayrıcalıklar mutabık kalınan sürenin ötesinde devam ediyorsa ya da ekip üretim verilerine kimin erişebileceğini açıklayamıyorsa kapı başarısızdır. Erişim, uygulama yerine destek araçları üzerinden gerçekleşse bile satıcı yöneticisini bir erişim yolu olarak değerlendirin.

Veri konumu bileşen düzeyinde harita gerektirir

Veri konumu, ekip her önemli kopyayı, işleyeni, aktarımı, yedeği ve destek yolunu hesaba katabildiğinde geçer. Uygulama iş yükü için ülke seçmek, bu iş yükünün konumunu kanıtlar; ilişkili tüm verilerin konumunu kanıtlamaz.

Yerleşim hakkında tek, belirsiz bir soruyla değil kategorilerle başlayın. Müşteri kayıtlarını, yüklenen dosyaları, kimlik bilgilerini, istemleri, üretilmiş kaynak kodunu, platform meta verilerini, günlükleri, izleri, model istek ve yanıtlarını, yedekleri, destek eklerini ve analitiği dahil edin. Her kategori için verinin nerede girdiğini, nerede durduğunu, hangi hizmetin işlediğini, nasıl taşındığını, ne kadar kaldığını ve kimlerin erişebildiğini kaydedin.

Bu ayrım, sık rastlanan bir hatayı yakalar: veri yerleşimi, veri işleme konumu ve aktarım denetimi ilişkili ancak farklı iddialardır. Veritabanı bir ülkede dururken model çıkarımı, telemetri analizi, destek erişimi veya olağanüstü durum kurtarma başka bir yere aktarım yaratabilir. Verinin bir bölgede «barındırıldığını» söyleyen satın alma dili çoğu zaman bu yolları yanıtsız bırakır.

Her kategori için benzersiz proje dizgesi ya da sentetik kayıt tanımlayıcısı gibi bir tohum işaretçisi kullanın. Satıcıdan bu işaretçinin uygulama depolamasında, operasyonel günlüklerde, yedeklerde, destek sistemlerinde ve model işlemede nerede görünebileceğini göstermesini isteyin. Hukuk ve güvenlik incelemecileri haritayı kabul edene kadar pilota gerçek kişisel veya düzenlemeye tabi verileri koymayın.

Alt işleyenler, işleme bölgeleri, destek erişimi, saklama, silme, şifreleme sahipliği ve olağanüstü durum kurtarma için belgesel kanıt isteyin. Satış görüşmesindeki sözlü güvence açık konu olarak kalmalıdır. Platform birden fazla model sağlayıcı kullanıyorsa kurumun bunları seçip sınırlayabildiğini, her birinin istekleri nerede işlediğini ve istemler ya da çıktılar için sağlayıcı saklaması olup olmadığını belirleyin.

Silmeyi gözlemlenebilir bir süreç olarak test edin. Tohum kayıt silindikten sonra etkin depolamada, günlüklerde, anlık görüntülerde, yedeklerde ve dışa aktarılan denetim materyalinde ne kaldığını sorun. Her yedekten anında kaldırma mümkün ya da istenir olmayabilir, ancak sağlayıcı saklama ve nihai sona erme davranışını kesin biçimde belirtmelidir. Bu davranışın yükümlülüğe uygun olup olmadığına hukuk ekibiniz karar verir; pilot ekibi gerçekten ne olduğunu kaydeder.

Veri haritası, güvenlik, gizlilik ve hukuk incelemecilerinin her yolu onaylayabilmesine yetecek kadar eksik değilse ve yapılandırma belgelenmiş konumla eşleşiyorsa geçin. Sağlayıcı yalnızca birincil veritabanı için yanıt veriyorsa, model işleme konumlarını belirleyemiyorsa, açıklanamayan destek erişimine izin veriyorsa veya yedek coğrafyasını gizli sayıyorsa kalın. Çözümlenmemiş konum, kabul edilebilir konum kanıtı değildir.

Dağıtım tek bir tarayıcı oturumunun dışında da tekrarlanabilir olmalıdır

Dağıtım, ekip sabitlenmiş bir revizyonu belgelenmiş, tekrarlanabilir bir süreçle yayınlayabildiğinde ve her ortama tam olarak neyin ulaştığını kanıtlayabildiğinde geçer. Başarılı önizleme URL'si sürüm denetimini kanıtlamaz.

Farklı kimliklere, sırlara, veritabanlarına, alan adlarına ve onay kurallarına sahip ayrı test ve üretim benzeri ortamlar oluşturun. Aynı kaynak revizyonu, gizli düzenleyici durumunu kopyalamadan ortamlar arasında taşınmalıdır. Yapılandırma değişebilir, ancak fark bildirilmiş ve incelenebilir olmalıdır.

Aynı revizyonu temiz durumdan iki kez dağıtın. Kaynak revizyonunu, bağımlılık kilidi sağlama toplamlarını, derleme sonucunu, geçiş sürümünü, yapılandırma referanslarını, onaylayanı, dağıtımı yapanı, başlangıç ve bitiş zamanlarını, hedef ortamı, sağlık kontrolü sonucunu ve oluşan sürüm tanımlayıcısını kaydedin. Sonra kayıtları karşılaştırın. Aynı girdi önemli ölçüde farklı yazılım üretiyorsa, üretimde kullanmadan önce ekibin bir açıklamaya ihtiyacı vardır.

Sürüm kaydı şu kısa yapıyı kullanabilir:

{
  "release_id": "rel-1042",
  "source_revision": "8f21c6a",
  "environment": "pilot-prod",
  "schema_version": "20260728_03",
  "requested_by": "oidc:00u81c",
  "approved_by": "oidc:00u19a",
  "result": "succeeded",
  "health_check": "passed"
}

Dağıtımı kasıtlı olarak başarısız kılın. Gerekli bir sırrı kaldırın, geçişi bozun, harici hizmete erişimi reddedin ve sağlık kontrolünü başarısız yapın. Sistem güvenli biçimde durmalı, hangi aşamanın başarısız olduğunu belirtmeli, tanısal kanıtı korumalı ve kısmi bir sürümü sağlıklı gibi göstermemelidir. Yalnızca «başarısız» bildiren dağıtım arayüzü, operatörleri olay sırasında tahmin yürütmek zorunda bırakır.

Politikanız gerektiriyorsa görev ayrımını test edin. Üretim kodunu değiştiren kişi, kendi onayını sessizce vermemeli veya denetim kaydını değiştirmemelidir. Ayrıca platform yöneticilerinin, üretilmiş uygulama yöneticilerinin ve bulut operatörlerinin ayrı yetkileri olup olmadığını belirleyin. Demo sırasında tek bir hesap her şeyi oluşturduğu için bu roller sıkça birleşir.

Yetkili başka bir operatör seçilen revizyonu dağıtabiliyor, yapılandırma referanslarını görebiliyor, onaylarını belirleyebiliyor ve satıcı yardımı olmadan sağlığını doğrulayabiliyorsa geçin. Dağıtım ilk sohbet oturumuna, adı belirtilmemiş en son sürüme, kişisel kimlik bilgilerine, değişebilir üretilmiş yapıtlara veya belgelenmemiş elle yapılan işe bağlıysa kalın.

Geri alma kodu, şemayı, veriyi ve yan etkileri kapsamalıdır

Geri alma, veri kaybını kabul edilen sınırda tutarken kabul edilen süre içinde tanımlı hizmet durumunu geri getirdiğinde geçer. Veritabanı veya harici yan etki zaten ilerlediyse, yalnızca uygulama kodunu geri çevirmek olayı kötüleştirebilir.

Alıştırmadan önce kurtarma süresi hedefi ve kurtarma noktası hedefi belirleyin. Kurtarma süresi, hizmetin ne kadar süre kesintide kalabileceğini ölçer. Kurtarma noktası, işletmenin ne kadar kaydedilmiş veriyi kaybedebileceğini ölçer. Ekipler çoğu kez son kayıtların kaybolup kaybolmadığını kontrol etmeden «geri alma altı dakika sürdü» der. Bu, sonucun yalnızca yarısını bildirir.

Kasıtlı olarak uyumsuz bir sürüm kullanın. A sürümü müşteri durumunu metin olarak saklar. B sürümü bunu yeni tabloya geçirir, API'yi değiştirir, test hizmeti üzerinden bildirim gönderir ve arka plan dönüşümü başlatır. Sürümlerden önce, sırasında ve sonra kayıtlar ekleyin; sonra dönüşümü kesip geri almayı tetikleyin.

İlk hata genellikle A sürümü B şemasıyla başlatıldığında görülür. Eski kod, geçişin kaldırdığı sütunu bekler. Bu nedenle yalnızca uygulamayı geri yüklemek ikinci kesintiyi üretir. Veritabanı anlık görüntüsünü geri yüklemek A sürümünü canlandırabilir, ancak anlık görüntüden sonra kaydedilmiş kayıtları atabilir. Entegrasyon idempotensi mekanizması kullanmıyorsa bu kayıtları yeniden oynatmak harici bildirimi çoğaltabilir.

Ekip, tek yöntemin her sürüme uygun olduğunu varsaymak yerine kurtarma tasarımı seçmelidir. Uyumlu genişlet ve daralt geçişleri, eski ve yeni kodun aynı şemada çalışmasına izin verebilir. Geri döndürülemez veri dönüşümünden sonra ileriye dönük onarım, tersine çevirmeden daha güvenli olabilir. İşletme kurtarma noktasını kabul ettiğinde ve ekip yeniden oynatmayı test ettiğinde anlık görüntü geri yükleme işe yarayabilir. Hangi yöntemin hangi geçiş sınıfına uygulandığını kaydedin.

Alıştırma sırasında algılama zamanını, karar zamanını, operatörü, onayı, uygulama sürümünü, şema sürümünü, anlık görüntü kimliğini, geri yüklenen kayıtları, kaybolan kayıtları, yeniden oynatma sonucunu, kuyruğa alınan işleri ve harici çağrıları yakalayın. Teknik sağlık kontrolleri geçtikten sonra işletme davranışını doğrulayın. Yeşil süreç izleyicisi, izinlerin, bakiyelerin, eklerin veya iş akışı durumunun doğru kaldığını kanıtlamaz.

Operatörler belgelenmiş kurtarma yolunu satıcı müdahalesi olmadan yürütüyor, her iki kurtarma hedefini karşılıyor, kayıtları mutabıklaştırıyor ve her harici yan etkiyi açıklayabiliyorsa geçin. Geri alma etiketsiz bir düğmeyse, şema uyumluluğu bilinmiyorsa, anlık görüntüler yalıtılmış ortama geri yüklenemiyorsa veya ekip veri kaybını hesaplayamıyorsa kalın.

Denetim kayıtları tartışmalı bir eylemi yeniden kurabilmelidir

Denetim yeteneği, incelemeci kimin neyi, hangi nesneye, ne zaman, nereden, hangi sonuçla ve hangi yetkiyle yaptığını belirleyebildiğinde geçer. Proje iş birliği için hazırlanmış kronolojik etkinlik akışı mutlaka denetim kaydı değildir.

NIST SP 800-53 Revision 5, AC-2'deki hesap yönetimini AU denetimlerindeki olay günlüğü ve denetim kaydı üretiminden ayırır. Bu ayrım mantıklıdır. Kimlik yönetimi hangi öznenin erişimi olduğunu belirler; denetim kaydı üretimi ise bu öznenin erişimi nasıl kullandığını kaydeder. Tartışmalı bir dağıtımı veya veri dışa aktarımını incelemek için her iki geçmişe de ihtiyacınız vardır.

NIST AU-3, olay türünü, zamanı, yeri, kaynağı, sonucu ve ilişkili kimliği içeren kayıtlar ister. Bu pilot için, uygun olduğunda kiracıyı, hedef nesneyi, istek ilişkilendirmesini, önceki ve yeni güvenlikle ilgili değerleri, kimlik doğrulama bağlamını ve onay referansını ekleyin. Günlük eksiksiz görünsün diye sır değerlerini, oturum belirteçlerini, kısıtlı veri içeren tam istemleri ya da hassas kayıt gövdelerini kaydetmeyin.

Faydalı bir olay şuna benzemelidir:

{
  "event": "role.assignment.changed",
  "time": "2026-07-28T14:03:22Z",
  "actor_sub": "oidc:00u81c",
  "actor_role": "platform-admin",
  "tenant": "tenant-204",
  "target": "user-771",
  "change": {"from": "viewer", "to": "manager"},
  "outcome": "success",
  "request_id": "req-9918",
  "approval_id": "apr-118"
}

Kimlik doğrulama hataları, rol değişiklikleri, oturum iptali, sır erişimi, kaynak dışa aktarma, veri dışa aktarma, yapılandırma değişikliği, dağıtım, geri alma, anlık görüntü kullanımı, alan adı değişikliği, destek erişimi, denetim dışa aktarma ve denetim ayarlarındaki değişiklikler için olay üretin. Başarıların yanı sıra başarısız denemeleri de test edin. İncelemeci çoğu zaman başarılı ayrıcalık değişikliğinden önce gelen reddi görmelidir.

Kullanıcının görünen adını ve e-posta adresini değiştirin, ardından önceki olayların kalıcı kimlikle bağlı kaldığını doğrulayın. Platform olaylarını, uygulama olaylarını ve kimlik sağlayıcı kayıtlarını ortak istek veya oturum referansı üzerinden karşılaştırın. Saat tutarlılığını kontrol edin, çünkü beş dakikalık kayma onay ile dağıtımın görünen sırasını tersine çevirebilir.

En güçlü pilot rolüyle denetim akışını değiştirmeyi, silmeyi, devre dışı bırakmayı ve taşırmayı deneyin. Saklamayı, dışa aktarma biçimini, sayfalamayı, saat dilimini, filtrelemeyi ve kayıtlar aranabilir hâle gelene kadar geçen süreyi doğrulayın. Kayıtları kurumsal denetimdeki depolamaya dışa aktarın ve dışa aktarmada incelemeye uygun kalıcı alan adları bulunduğunu onaylayın. İndirilebilir elektronik tablo analiste yardımcı olabilir, ancak hücreler yapılandırılmış değerleri kesiyorsa tek gösterim biçimi olmamalıdır.

Teste katılmamış incelemeci, dışa aktarılan kanıttan tohumlanmış olayı yeniden kurabiliyor ve günlüğü zayıflatma girişimlerini saptayabiliyorsa geçin. Yöneticiler kendi izlerini silebiliyorsa, kimlikler ilişkilendirilemiyorsa, başarısız eylemler kayboluyorsa, destek etkinliği görünmüyorsa veya saklama belgelenmemiş plan katmanına bağlıysa kalın.

Geliştirici devri gizli platform bağımlılığını ortaya çıkarır

Geliştirici devri, pilotu oluşturmamış bir geliştirici dışa aktarılan uygulamayı ilk oluşturucu ya da platform olmadan bakımını yapıp yayımlayabildiğinde geçer. Kodun okunabilirliği önemlidir, ancak başarılı sahiplik devri daha güçlü testtir.

Kodu devralan geliştiriciye temiz ortamı, kaynak dışa aktarma çıktısını, mimari notları, yapılandırma referansını, veri modelini, geçiş geçmişini, test talimatlarını, dağıtım prosedürünü, kurtarma prosedürünü, bağımlılık envanterini ve bilinen sınırlamaları verin. Alıştırma sırasında platform erişimini kaldırın. İlk oluşturucu gözlem yapabilir, ancak süre ve engeller kaydedilene kadar uygulama sorularını yanıtlamamalıdır.

Rapor sorgusunda eksik kiracı filtresi gibi sıradan bir hata ekleyin. Geliştiriciden hatayı yeniden üretmesini, yetkilendirme yolunu bulmasını, gerileme testi eklemesini, sorguyu düzeltmesini, küçük bir şema değişikliği yapmasını, tüm test takımını çalıştırmasını, test ortamına dağıtmasını ve geri alma yolunu açıklamasını isteyin. Bu sıra, makul görünen ancak tutarlı sınırları veya test bağlantı noktaları olmayan üretilmiş kodu ortaya çıkarır.

Devri üslup tercihine göre değil, kanıta göre değerlendirin. Kurulum süresini, belgelenmemiş bağımlılıkları, başarısız komutları, belirsiz sahipliği, değişen yol çevresindeki test kapsamını, inceleme bulgularını, dağıtım sonucunu ve satıcı bilgisi gerektiren soruları kaydedin. Geliştiriciden güvenle düzenlenebilen üretilmiş alanları ve sonraki sohbet değişikliklerinden sonra platformun üzerine yazabileceği alanları belirlemesini isteyin.

Yeniden üretmeye yakından dikkat edin. Dışa aktarımdan sonra geleneksel kod düzenlemesi yapın, destekleniyorsa projeyi içe aktarın veya yeniden bağlayın, ardından yakında platformun ürettiği bir değişiklik isteyin. Platformun elle yapılan düzenlemeyi koruyup korumadığını, yeniden yazıp yazmadığını, çoğaltıp çoğaltmadığını veya sessizce çakıştırıp çakıştırmadığını belirleyin. Ekiplerin insan ve üretilmiş işin birlikte yürütülmesi için açık çalışma modeli gerekir. «Geliştiriciler kodu düzenleyebilir» ifadesi, sonraki üretimde ne olduğunu açıklamaz.

Uygulamanın tekrarlanabilir testleri yoksa, veri modeli yalnızca sohbet geçmişinde bulunuyorsa, üretilmiş modüllerin kalıcı sınırları yoksa, elle yapılan değişiklikler kayboluyorsa veya dağıtım hâlâ ilk oluşturucunun hesabını gerektiriyorsa devir başarısızdır. Aynı sistemin ürettiği dokümantasyon yardımcı olabilir, ancak devralan geliştirici bunu kod ve çalışma zamanına göre doğrulamalıdır.

Temiz bir devir, her geliştiricinin üretilmiş üsluba hayran kalmasını gerektirmez. Yetkin bir geliştiricinin değişikliğin etkisini öngörmesini, davranışı test etmesini, güvenliğe duyarlı yolları incelemesini ve özel bilgi olmadan sürümü çalıştırmasını gerektirir.

Sözleşme, kanıtladığınız delili korumalıdır

Sözleşme, her engelleyici denetim geçtiğinde veya kurum telafi edici denetimle birlikte belirli ve süreli bir istisnayı resmen kabul ettiğinde ilerlemelidir. Satın alma ekibi, özellik adlarına güvenmek yerine kanıt tanımlarını ticari taahhüde eklemelidir.

Koder.ai değerlendirmesi için kaynak dışa aktarma, dağıtım, barındırma, özel alan adları, anlık görüntüler, geri alma, planlama modu ve ülkeye özgü uygulama konumlandırmasını aynı kanıt kurallarına tabi tutun. Özellik adı test etmeye davettir, kanıt değildir.

Karar kaydını yedi denetim hükmü çevresinde oluşturun. Her biri için test edilen revizyonu, ortamı, kanıt sahibini, gözlemlenen sonucu, satıcı yardımını, kusur referansını, yeniden test sonucunu ve sözleşme sonucunu ekleyin. Ham yapıtları kurumsal denetimdeki depolamada tutun. Böylece sonraki incelemeci, ekibin gözlemlediklerini tarafların konuştuklarından ayırabilir.

Çözümlenmemiş engeli taşınabilirliği, yerleşimi veya kurtarmayı «desteklemeye» yönelik belirsiz bir sözleşme taahhüdüne dönüştürmeyin. Yapıtı veya davranışı tanımlayın: belirtilen süreçte eksiksiz kaynak dışa aktarma, adlandırılmış işleme konumları, dışa aktarılabilir denetim alanları, test edilmiş geri yükleme yolu ya da ilişki sona erdikten sonra gerekli derleme materyallerine devam eden erişim. Benimseme açısından önemli iddialar için çözüm ve çıkış hakkı belirleyin.

Devir koşullarını da koruyun. Üretilmiş kaynak kodunun sahipliğini ve izin verilen kullanımını, dışa aktarımlara erişimi, veri iadesini, silme davranışını, yapılandırma alma imkânını, denetim dışa aktarmayı, geçiş yardımını ve ilişki bittiğinde zaten dağıtılmış uygulamalara uygulanacak işlemi belirtin. Ticari katmanlar farklı olabilir, ancak ekip imzalamadan önce test edilen hangi denetimlerin seçilen katmana bağlı olduğunu bilmelidir.

Koşullu geçiş için sahip ve bitiş tarihi gerekir. Gerçek düzeltmeyi aynı ortamda yeniden test edin ve özgün kanıt kaydını güncelleyin. Planlanan işlevi anlatan slayt başarısız testi kapatmaz; satıcının hazırladığı projedeki demo da düzeltmenin sizin projenize uygulandığını kanıtlamaz.

Pilot, geliştirme heyecanı geçtikten sonra da karar açık kaldığında görevini yapmıştır. Ekip uygulamayı kendi denetiminde dışa aktarabiliyor, sınırlayabiliyor, konumlandırabiliyor, dağıtabiliyor, kurtarabiliyor, inceleyebiliyor ve devredebiliyorsa, sözleşme gözlemlenmiş yeteneğe dayanır. Bu kapılardan biri hâlâ bir açıklamaya bağlıysa, maliyet düşükken başarısızlığı kaydedin.