Zamanlanmış bir SQL işi veya genel API üretim altyapısının parçasıdır; buna rağmen birçok ekip bunları kişisel elektronik tablolar gibi değiştirir: talep kaydı, ekip arkadaşı incelemesi veya geri alma planı olmadan.
iDataEngine, REP tasarımlarını, SQL projelerini, API servislerini, MF şablonlarını ve AccessGuard taramalarını tek bir web kokpitinde merkezileştirir. Yönetişim, bu artefaktları gölge BT'ye aktarmak değil; onlara değişiklik kontrolü uygulamak demektir.
Kontrollü değişiklik olarak ele alınması gerekenler
- SQL projesi — yöntem, delta parametresi, bağlantı veya zamanlama değişikliği
- API servisi — sabit filtre, alan kümesi, URL uzantısı, güvenlik sınırları, aktif bayrak
- REP iView — yeni alanlar, join değişiklikleri, kayıttan sonra aktivasyon
- AccessGuard — SoD kural düzenlemeleri, özel tarama tanımları
- BI nesneleri — yayımlama, rol ataması ve önbellek yenileme işleri
Platform; uygulama günlükleri, servis günlükleri, iş izleme geçmişi, API Monitor, AccessGuard anlık görüntüleri ve istek günlükleriyle kanıt sağlar. E-posta yazışmaları yerine bunları denetim izi olarak kullanın.
Hafif bir değişiklik kontrolü modeli
- Nesne kimliğine (proje adı, servis adı, iView kimliği) atıfta bulunan bir değişiklik kaydı açın
- Üretim dışında test edin (Test Service, SQL Test, iView Test)
- Onaylı bir pencerede kaydedin — API URL'leri her kayıtta yenilenir; yeni GUID'leri iletin
- Canlıya geçişten sonra bir AccessGuard veya iş izleyici başlangıç anlık görüntüsü alın
- Geri almayı tanımlayın: API'yi devre dışı bırakın, işi durdurun veya önceki iView sürümünü transport'tan geri yükleyin
Neden önemli?
Değişiklik disiplini olmadan hız, "bozulana kadar üretimde çalışır" türü entegrasyonlar doğurur. Kokpit yapılandırması sürümlendiğinde, test edildiğinde ve anlık görüntülerle ilişkilendirildiğinde kurumsal titizlikten ödün vermeden düşük kod avantajını korursunuz. Buradaki yönetişim bürokrasi değil, inovasyonu yalnızca ilk API ve iş için değil sonraki yüz tanesi için de tekrarlanabilir kılma yöntemidir.