← Tüm projeler Vaka çalışması · İç araç

Arama yayını

Search V2 hazırdı. Onu uygun her mağazaya ulaştırmak ayrı bir projeydi. Her sitenin zaten çalıştırdığı loader üzerinden kurulum yapan, tek bir marka sitesine dokunmayan ve varsayılanı dry-run olan bir TypeScript CLI yazdım.

  • 271/ 272 markada canlı
  • 7komut, varsayılan dry-run
  • 8marka durum sınıfı
  • ~1,5 binsatır TypeScript, build yok
  • Ağu2026
Deneyin

Aramayı örnek markalara yayınlayın

Discover, Plan, ardından Apply --apply ve Verify çalıştırın. Config farkını ve yedeğini görmek ya da geri almak için bir markaya tıklayın.

search-rollout · örnek marka grubuEtkileşimli demo
Etkileşimli CLI için JavaScript gerekiyor. Uydurma markalardan oluşan bir filoya discover, plan, apply, verify, deconflict, report ve rollback çalıştıran bir terminal ve yanında canlı bir durum panosu gösteriyor.
Marka adları ve ID'ler uydurma. Komutlar, durum sınıfları ve güvenlik kuralları gerçek araçla aynı.
Sorun

Bir mağaza scriptini yüzlerce markaya elle kurmak, birinin canlı sitesini bozmak için yüzlerce fırsat demek.

Her markanın kendi arama config'i, kendi widget seti ve bazen koşulsuz çalışan eski araması vardı. Bazı config'ler kapalıydı, bazı arama indeksleri boştu, bazı input seçicileri artık canlı siteyle eşleşmiyordu. Ortak bir durum bayrağını açmak eski aramayı da her ziyaretçi için geri açıyordu.

Rolüm

Aracı tasarlayıp yazdım, pilotu ve ardından tam yayını yaptım, bulduğu tuzakları belgeledim. Mevcut panel endpointleriyle konuşuyor; mağazalarda hiçbir şey değişmedi.

  • discover her müşteri ID'sini tarar, arama sağlığını kontrol eder, mevcut widgetları listeler
  • plan bir fark üretir, canlıya hiçbir şey göndermez
  • apply --apply verilene kadar dry-run kalır; her markayı yedekler, yazar, geri okur
  • verify config, widget, script host ve arama sonuçlarını bağımsız kontrol eder
  • Uç durumlar için deconflict, report ve rollback --confirm
Mimari

Marka marka, her adımda geri alınabilir

  1. DiscoverHer markayı sınıflar: ready, stale-selector, loader-unconfirmed, search-empty, disabled ve diğerleri.
  2. PlanYalnızca hazır markalar için fark. Canlıya istek yok.
  3. ApplyYedekle, tam config nesnesine birleştir, yaz, geri oku.
  4. Mevcut loaderHer sitenin zaten çalıştırdığı widget loader'ı yeni arama widget'ını alır.
  5. Verify + raporBağımsız kontroller ve test linkli tek dosyalık HTML rapor.

Mor ton: benim yazdığım kısımlar.

Mühendislik kararları

Zor olan neydi, ne yaptım

Varsayılan güvenli

--apply olmadan apply hâlâ dry-run. Gerçek yazma bir bayrak istiyor ve --limit ya da --ids ile birkaç markaya sınırlanabiliyor; pilot geri kalanından önce birkaç markada çalışıyor.

Markanın kendi emeğini asla ezme

Kayıt endpointi tüm config nesnesini değiştiriyor; araç her zaman okuyor, birleştiriyor ve tam nesneyi gönderiyor. Markanın mevcut CSS'i asla ezilmiyor, eski aramanın CSS'ine dokunulmuyor, kapalı bir marka sessizce açılmıyor.

Tek bayrak, iki ürün

Eski ve yeni arama aynı durum bayrağını okuyor. V2 için açmak bazı markalarda V1'i tüm ziyaretçilere gösterecekti; bu yol --allow-v1-exposure verilmedikçe kapalı, o markalar ise listeleniyor.

Apply'dan ayrı doğrulama

Geri okuma yazmanın gittiğini kanıtlıyor. verify sitenin çalıştığını kanıtlıyor: script host dosyayı gerçekten servis ediyor ve arama endpointi hâlâ ürün döndürüyor. Eski bir widget'tan kopyalanan bir subdomain bir keresinde DNS'te hiç yoktu.

Yenisiyle çakışan eski widgetlar

Bazı markalar her sayfada kendi eski arama widget'ını çalıştırıyordu; demo linkinde ikisi aynı input'a bağlanıyordu. deconflict eskisini yalnızca demo linkinde kapatan bir URL kuralı ekliyor; normal ziyaretçi hiçbir fark görmüyor.

Tuzakları yaz

Loader widget listesini oturum boyunca cache'liyor; eski bir sekmede açılan test linki hiçbir şey göstermiyor. Pilot tam olarak buna takıldı. README artık sebebiyle birlikte yeni sekmede test etmeyi söylüyor.

Çözmeye değer bir problemin mi var?Birlikte çözelim

Konuşmaya başla

Full-stack ve uygulamalı AI rollerine açığım, uzaktan veya hibrit.

Rolü, ekibi ve problemi anlat.