Bir Windows Box'ta Dev Makinesini Güvenle Aynalamak

Bugün tertemiz kurulan bir araç, üç hafta sonra “diğer hesapla giriş yapınca neden çalışmıyor” diye bir bug’a dönüşür. Hatayı bildiren de benim, muhatabı da; üstelik buna yol açtığımı çoktan unutmuş olurum. İki login’li bir box’ta dev makineni tek bir login profiline aynalarsan başına gelen tam olarak budur.

Box, bu serinin önceki bölümlerinde kurduğum yollarla zaten erişilebilirdi. Ama erişilebilir olması onu bir workstation yapmıyordu; sıradaki iş, Mac’imdeki stack’i box’a aynalamaktı: aynı Node, aynı CLI’lar, aynı VS Code extension’ları, aynı Android SDK. iOS hariç — o Apple’ın duvarlarla çevrili bahçesi, Mac’te kalıyor.

Kolay olan kısım kurulumlardı: winget, nvm, git clone — aynı gün bitti. Asıl iş, bunların altındaki disiplindi ve tek bir kurala iniyordu: bir kez kur, machine-wide kur, ki iki login kimliği de aynı kurulumu paylaşsın.

Kullanıcı-Bazlı Varsayılan: Gelecekteki Sana Kurulan Tuzak

Windows dev tooling’i tek bir kullanıcının profiline kurulmaya bayılıyor; kulağa yardımsever geliyor, oysa yukarıda anlattığım mayın tam da bu. Ben de bulabildiğim her kullanıcı-bazlı varsayılanın peşine düştüm ve hepsini teker teker bir üst seviyeye taşıdım.

Node, nvm üzerinden gelmiş ve tek bir kullanıcının profiline yerleşmişti; söküp attım, yerine her iki hesabın da işaret ettiği paylaşımlı bir npm prefix’le machine-wide bir Node LTS kurdum. winget’in “portable” CLI’ları (ffmpeg, jq, ripgrep, uv) kendilerini kullanıcı-bazlı bir dizine shim’lemişti; geçici çözüm olarak gerçek executable’ları sistem PATH’indeki machine-wide bir araç klasörüne kopyaladım. İşe yarıyor, ama bu tür kopyalar winget’in upgrade yolunun dışında kalıyor, yani kendi başlarına güncellenmiyorlar. VS Code extension’larını ise doğrudan Mac’ten aynaladım, iki yöne de tek satır:

# on the Mac
code --list-extensions > ext.txt

# on the box, loop and install
Get-Content ext.txt | ForEach-Object { code --install-extension $_ }

Android SDK, Part 2’deki 27.6 GB’lık temizlikten sağ çıkmıştı; sadece diskte sahipsiz kalmıştı. sdkmanager ile onu Mac’in platform ve build-tools’larıyla eşleştirdim, lisansları kabul ettim, ANDROID_HOME‘u da machine seviyesinde ayarladım.

Hiç Kimsenin README’ye Koymadığı Gotcha’lar

Bayat bir x86 dotnet, gerçeğinin önüne geçip onu gölgeliyordu. .NET 10’u (x64) kurmuştum, dotnet --version yazınca daha eski bir cevap geldi: eski günlerden kalma, 32-bit antika bir dotnet PATH’te daha önde oturuyor ve aramayı o kazanıyordu. where.exe dotnet iki girdi gösterdi; x86 olanı kaldırdım. Part 2’deki PATH-hijyeni dersinin yeni kılığa girmiş hali.

ngrok sorunsuz indi, ama arkasından Windows Defender onu yedi; Potentially Unwanted Application diye işaretledi. Uğraşmaya değmezdi: cloudflared zaten kuruluydu ve aynı işi görüyordu, ben de ngrok’u geçtim.

npm, cmd‘de sorunsuz çözülüyor ama PowerShell’in & call operator’üyle çözülmüyor: bozuk bir kurulum değil, sadece bir tuhaflık. Can sıkıcı ama zararsız; yine de tam olarak seni ‘Node’u bozdum’ sanısına düşürüp kırk dakikanı yiyen türden bir şey.

nvm uninstaller askıda kaldı. nvm-yönetimli Node’u machine-wide LTS’yle değiştirirken SSH üzerinden gelen interaktif bir ‘emin misin?’ promptunda taş kesildi — cevap verecek bir TTY yoktu, öylece bekledi. Process’i öldürüp kalıntıları elle temizledim.

Assistant’ın kendi safety layer’ı, bir bulut CLI’ındaki zararsız bir version check’i bile yanlış işaretledi; guardrail durup dururken devreye girdi.

Her araçta hedefim, varsayılanın machine-wide olmasıydı. VS Code extension’ları ve npm’in global paketleri tasarım gereği kullanıcı-bazlı; o yüzden onlar oturum açtığım hesapta kaldı, ikinci hesabı hizaya getirmekse sonraya kalan bir işti.

Emulator Neden Box’ta Çalışıyor

Mac’teki emulator, Apple Silicon üzerinde öyle ağır çalışıyordu ki emulator’ü ve daha ağır Android build’lerini tümüyle box’a taşıdım; publish işini yine de Mac’in kendisinde tuttum.

Box, x86_64 bir system image’ı native çalıştırıyor, hardware acceleration için WHPX kullanıyor, GPU rendering’i de RTX 3060’a devrediyor — emulator’ün mutlu yolu tam olarak bu. Mac beyin, box kas; ve burada kas daha hızlı.

Setup çoğunlukla olaysızdı: emulator’ü kur, bir Google-APIs x86_64 system image’ı çek, bir AVD yarat. Tek gerçek gotcha accelerator’dı: Hyper-V tek başına yetmiyor, emulator özellikle Windows Hypervisor Platform feature’ını istiyor:

Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All
# reboot, then:
emulator -accel-check
# accel:
# 0
# WHPX is installed and usable.

Peşine düştüğün satır işte o son satır — o gelmeden accel-check, WHPX’i kullanılabilir diye raporlamaz.

Sildiğimi Sandığım Repo

Emulator’ü gerçek bir workflow’a bağlamak için eski Android auto-setup script’lerimi aramaya koyuldum — AVD provisioning, gradle warm-up, bir kez yazıp sonra hep yeniden kullandığın boilerplate. Bir an yok olduklarını sandım; sonra nerede olduklarını hatırladım: eski bir client işi, kendi izole ağacında duruyordu — kurup yarı yarıya unuttuğum bir sınırın ardında.

Silinmemişlerdi; sadece düzgünce izole edilmişlerdi. Sınır da tam amaçlandığı gibi tuttu: o ağacı hiç açmadım, bir client projesinden buraya hiçbir şey geçmedi.

Client işi, kişisel iş ve bu home lab aynı klasörü paylaşmaz. Client’ın uygulaması da konfigürasyonu da kendi izole ağacında kalıyor; oradan buraya bir şey taşımak, eski bir script’i geri istememin yan etkisi olmaz, bilerek vereceğim bir karar olur.

Böylece emulator sıfırdan kuruldu: genel ve temiz, ne bir şey ödünç alındı ne de bir şey taşındı.

Sırada: Claude Code box’a iniyor ve memory framework’üm de kendi temizliğinden geçiyor.