Tasarımcılar için Geliştirme Ortamı ve Üretim: 2026 Kılavuzu

Çoğu tasarımcı, geliştirme, test ve üretim ortamlarını yanlış ortamda bir şeyleri bozarak öğrenir. Bir Loom gönderilir. Bir mühendis yüzünü buruşturur. Slack başlığı "bekleyin, bu hangi URL?" diye başlar. İşte tüm işe alım süreci bu kadar.

İşte ilk günden almanız gereken açıklama buydu. Gereksiz jargon yok, el kol sallama yok, sadece üç ortam, her birinde kimin yaşadığı ve bir tasarımcı olarak onlarda ne yapmanız gerektiği.

Yanlış sekmeye bakarken "bu henüz yayında mı?" diye sorduysanız, bu makale tam size göre.

Üç Ortamın Var Olmasının Nedenleri

Yazılımın, fiziksel ürünlerde olmayan bir sorunu vardır. Bir kez gönderildikten sonra, herkese hemen, aynı anda gönderilir. Fabrika katı yok, test pazarı yok, varsayılan olarak yavaş bir dağıtım yok. Kötü bir değişiklik, bir sayfayı yenileme süresinde milyonlarca kullanıcıyı etkileyebilir.

Üç ortam, ekibe kullanıcılar yanlışlığı görmeden önce yanlış yapma alanı sağlamak için vardır. Geliştirme aşamasında çok yanlış yapmanıza izin verilir. Test aşamasında biraz yanlış yapmanıza izin verilir. Üretim aşamasında ise hiç yanlış yapmanıza izin verilmez, çünkü gerçek insanlar sizi izliyor.

Bunu, aynı makalenin üç editörlük aşamasından geçmesi olarak düşünebilirsiniz. İlk taslak kaba, prova baskısı çoğunlukla temiz, basılı dergi on kişi tarafından okunmuş. Kimse ilk taslağı yayınlamaz ve kimse aynı nedenle doğrudan üretime geçmez.

Aşamaları atlayan ekipler bunu küçük, hızlı veya dikkatsiz oldukları için yaparlar. Bazen üçü birden. Yapı, ekibin yavaşlamadan dikkatsizlikten kurtulabilmesi için mevcuttur.

Üç Ortam Hile Sayfası

Daha derine inmeden önce, ekran görüntüsünü alıp bir daha asla sormanıza gerek kalmayacak hile sayfası burada:

| Ortam | Amaç | Hedef Kitle | Veri | URL kalıbı | Dağıtım tetikleyicisi | İnceleme stili |

|---|---|---|---|---|---|---|

| Geliştirme | Özgürce geliştirin ve bozun | Bir mühendis, bazen siz | Sahte veya önceden yüklenmiş, genellikle bozuk | localhost:3000 veya yourname.dev.app | Yerel kod değişiklikleri | Eşleştirme, ekran paylaşımı |

| Hazırlık Ortamı | Kullanıcılardan önce son kontrol | İç ekip, tasarımcılar, QA | Gerçekçi, anonimleştirilmiş, güncellenmiş | staging.app.com veya pr-123.app.com | PR birleştirme veya manuel itme | Asenkron inceleme, Loom, Figma karşılaştırma |

| Üretim Ortamı | Gerçek şey | Müşteriler, dünya | Gerçek, hassas, geri döndürülemez | app.com | Etiketli sürüm veya ana dal birleştirme | İzleme, lansman sonrası QA |

Sadece bir satırı hatırlayacaksanız, veri satırını hatırlayın. Geliştirme ortamında sahte veriler, hazırlık ortamında gerçekçi veriler, üretim ortamında ise müdahale ederseniz dava edilmenize neden olacak veriler bulunur. Üçüne de buna göre davranın.

Geliştirme: Mühendislerin Yaşadığı Yer, Şeylerin Bilerek Bozulduğu Yer

Geliştirme ortamı, bir mühendisin dizüstü bilgisayarında veya kişisel bulut sanal ortamında çalıştırdığı her şeydir. Genellikle localhost olarak adlandırılır. Makinelerinde çalışır, sahte bir veritabanıyla iletişim kurar ve aynı anda tam olarak bir kişi için mevcuttur. Bu ortamı neredeyse hiç görmezsiniz ve bu doğrudur.

Bir mühendis "benim makinemde çalışıyor" dediğinde, geliştirme ortamından bahsediyordur. Zamanın yarısında orada çalışmasının nedeni verilerin sahte olması, ağın hızlı olması ve başka hiçbir şeyin olmamasıdır. Zamanın diğer yarısında ise beş dakika önce bitirdikleri ve gerçekliğe benzeyen hiçbir şeye karşı test edilmediği için orada çalışır.

Geliştirme ortamı aynı zamanda yeni bileşenlerin ilk ortaya çıktığı yerdir. Figma'de bir kart deseni teslim ettiyseniz, gerçek kodda ilk kez bir mühendisin geliştirme ortamında var olur. Muhtemelen size localhost'tan bir ekran görüntüsü veya Loom ile ping atacaklardır. Bu, size son hali değil, kaba taslağı göstermeleridir.

Geliştirme ortamında piksel cilası için inceleme yapmazsınız. Geliştirme ortamını, yapıyı, davranışı ve amacı doğrulamak için gözden geçirirsiniz. Piksel notlarını test ortamı için saklarsınız.

Test Ortamı: Genel Prova

Test ortamı, ekibin müşterilerden önce kendini kontrol ettiği yerdir.

Gerçekçi verilerle, genellikle normal alan adınızın önüne "test ortamı" kelimesi eklenmiş bir URL üzerinde, gerçek altyapı üzerinde çalışır.

Ekipteki herkes bakabilir. Müşteriler bakamaz.

Tasarım incelemenizin çoğunu burada yaparsınız. Figma dosyasıyla karşılaştırırsınız. Gerçek bir cihazda akışı incelersiniz. Figma dosyasında her zaman iyi görünen ancak kodda garip olan şeyleri yakalarsınız: satır yükseklikleri, odak durumları, bir isim kırk karakter uzunluğunda olduğunda ne olur, hiç veri olmadığında ne olur.

Test ortamı genellikle ekibin karşılayabileceği kadar üretim ortamını yansıtır. Aynı veritabanı yapısı, test modunda aynı üçüncü taraf hizmetleri, aynı özellik bayrakları, aynı yetkilendirme akışı. Test ortamı üretim ortamına ne kadar yakınsa, bir şey piyasaya sürüldüğünde o kadar az sürprizle karşılaşırsınız. Test ortamının üretim ortamından uzaklaşmasına izin veren ekipler, ücretsiz olarak yakalayabilecekleri hataları piyasaya sürmekle sonuçlanırlar.

Test ortamı aynı zamanda mühendisin tasarımınızı sizin kastettiğiniz gibi yorumlayıp yorumlamadığını öğrendiğiniz yerdir. Çoğu zaman öyle olmuştur. Diğer yarısı ise asıl konuşmanın başladığı yerdir.

Üretim: Gerçek İnsanların Yaşadığı Yer

Üretim, canlı sitedir. Müşterilerinizin URL'nizi bir tarayıcıya yazdıklarında gördükleri şeydir. Gerçek altyapı üzerinde, gerçek verilerle, üzerinden geçen gerçek parayla, her değişikliğin gerçek sonuçlarıyla çalışır. Tıkladığınızda, kullanıcılarınızın etkileşimde bulunduğu aynı sistemle etkileşim kurarsınız.

Bu, tasarımcı olmaktan çıkıp misafir olmaya başladığınız ortamdır. Üretim ortamında fikirleri test etmek için tıklama yapmazsınız. Bir şeyleri denemezsiniz. Ne olacağını görmek için sahte bir kullanıcı olarak giriş yapmazsınız, çünkü üretimde sahte kullanıcı yoktur, yalnızca yanlışlıkla bozabileceğiniz gerçek kayıtları olan gerçek kullanıcılar vardır.

Üretim ortamı, izleme, dağıtımdan sonra anlık kontroller ve zaten canlı olan şeylerin ekran görüntülerini almak içindir. Bir şeyi test etmeniz gerekiyorsa, hazırlık ortamına geri dönersiniz. Hazırlık ortamı size o şeyi gösteremiyorsa, önizleme istersiniz. Üretim ortamına dokunmazsınız.

Herhangi bir ekibin olgunluk testi, bu kurala ne kadar bağlı olduklarıdır. Genç ekipler sürekli olarak üretim ortamını inceler. Kıdemli ekipler ise onu temiz bir oda gibi ele alır.

Tek Bir Değişikliğin Yaşam Döngüsü

Tek bir tasarım değişikliği, bir kullanıcı onu görmeden önce her ortamdan geçer. Bu yaşam döngüsünü bilmek, mühendisleri hayal kırıklığına uğratan tasarımcıları, onları memnun eden tasarımcılardan ayıran şeydir.

İşte bir değişikliğin gerçekte nasıl ilerlediği:

1. Tasarımı, açıklamalar, durumlar ve uç durumlarla birlikte Figma'te teslim edersiniz.

2. Bir mühendis değişikliği geliştirme ortamına çeker ve yerel olarak derler.

Ardından çalışma ekibe açık hale gelir:

3. Benzersiz bir URL ile önizleme dağıtımını başlatan bir çekme isteği açarlar.

4. Önizlemeyi incelersiniz, yorum bırakırsınız, değişiklik talep edersiniz, onaylarsınız.

Ve sonunda kullanıcılara ulaşır:

5. PR birleşir ve değişiklik, son bir ekip incelemesi için test ortamına gönderilir.

6. Test ortamı onaylandıktan sonra, değişiklik üretim ortamına gönderilir ve kullanıcılar bunu görür.

Üçüncü ve dördüncü adımlar yeni süper güçtür. Önizleme dağıtımları, kod halindeki çalışmanızı test ortamında görmek için beklemenize gerek olmadığı anlamına gelir. Mühendis dalını gönderdiği anda görürsünüz. Bu eskiden bir lüksken, şimdi olmazsa olmaz bir özelliktir.

Ekibinizde önizleme dağıtımları yoksa, ekleyebilecekleri en etkili şey budur. Bunun için çaba gösterin.

Önizleme Dağıtımları Her Şeyi Değiştirdi

On yıl önce, tasarım incelemesi ya mühendisin masasına uçmak ya da bir sonraki Salı günkü test ortamı gönderimini beklemek anlamına geliyordu. Bugün, her modern barındırma platformu her çekme isteğine kendi URL'sini veriyor. Vercel bunlara önizleme dağıtımları diyor, Netlify bunlara dağıtım önizlemeleri diyor, Render, Cloudflare ve AWS Amplify de aynı şeyin farklı versiyonlarını yapıyor.

Bu pratikte şu anlama geliyor: her dal, her çekme isteği (PR), her devam eden değişiklik, hiçbir şey beklemeden inceleyebileceğiniz canlı, tıklanabilir bir URL'ye sahip. Mühendis dalını gönderiyor, önizleme iki dakika içinde oluşturuluyor ve bir bot URL'yi sizin için çekme isteğine bırakıyor. Tıklıyorsunuz, inceliyorsunuz, yorum yapıyorsunuz, devam ediyorsunuz.

Önizleme dağıtımları, tasarım inceleme döngüsünü günlerden dakikalara indiriyor. Ayrıca Loom videolarını çok daha az gerekli hale getiriyorlar, çünkü önizleme URL'si etkileşim kurabileceğiniz bir Loom videosu. Eğer bunları kullanmadıysanız, mühendisinizden herhangi bir açık çekme isteğindeki bot yorumuna bakmanızı isteyin. Bağlantı hemen orada.

Önizlemeler hakkında bilmeniz gereken birkaç şey: Bunlar asla üretim verileriyle değil, hazırlık veya test verileriyle çalışır. Geçicidirler ve çekme isteği kapandıktan sonra kaldırılırlar. Her dalın kendi URL'si vardır, bu nedenle on farklı özellik için aynı anda on tanesini açık tutabilirsiniz.

Ortam Değişkenleri, Yapılandırmalar ve Neden "Test Modu" Gördüğünüz

Her ortam aynı kodu çalıştırır ancak farklı servislerle iletişim kurar. Geliştirme ortamı test veritabanını, hazırlık ortamı hazırlık veritabanını, üretim ortamı ise gerçek veritabanını kullanır. Her ortam ayrıca her üçüncü taraf aracın farklı sürümlerini kullanır: Geliştirme ve hazırlık ortamlarında test modunda Stripe, üretimde canlı modda Stripe. E-posta göndericileri, analitik, kimlik doğrulama ve her harici bağımlılık için de aynı durum geçerlidir.

Ekiplerin tüm bunları düzenli tutmasının yolu, yapılandırmalar veya sırlar olarak da adlandırılan ortam değişkenleridir. Bunlar, her ortam için değişen DATABASE_URL veya STRIPE_KEY gibi küçük adlandırılmış değerlerdir. Doppler, Vercel ortam değişkenleri, AWS Secrets Manager veya 1Password Connect gibi araçlar bunları yönetir.

Tasarımcı olarak bu sizin için neden önemli: Stripe'nin test ortamında test kartı numaralarını gösterdiğini gördüğünüzde, bu test ortamındaki Stripe anahtarının konuştuğu anlamına gelir. Geliştirme ortamında kendi profil resminizi görürken tamamen sahte bir kredi kartı görüyorsanız, bu geliştirme ortamının sahte bir veritabanından veri çektiği ancak gerçek bir Clerk yetkilendirmesi kullandığı anlamına gelir. Bir şey test ortamında çalışırken üretim ortamında bozuluyorsa, vakaların %90'ında eksik veya farklı bir ortam değişkeni söz konusudur.

Bunları yönetmenize gerek yok. Sadece var olduklarını bilmeniz yeterli, böylece bir mühendis "bekleyin, bu üretim Stripe anahtarını kullanıyor, o düğmeye tıklamayın" dediğinde ne demek istediğini anlarsınız.

Veri Eşitliği: Gerçekte Görecekleriniz

Her ortamın içindeki veriler, neyi test edebileceğinizi ve neyi test edemeyeceğinizi belirler. Tasarımcıların en sık gözden kaçırdığı şey budur.

Geliştirme ortamında genellikle küçük bir sahte kullanıcı, sahte ürün, her şeyin sahte olduğu bir veri seti bulunur; bu veri seti genellikle her sabah silinir ve yeniden oluşturulur. İsimler saçma olur, adresler Springfield'den olur, avatarlar küçük gri kareler olur. Boş durumları veya uç durumları bu veriler üzerinde değerlendirmeye çalışmayın, çünkü bu veriler mutlu senaryonun çalışmasını sağlamak için oluşturulmuştur.

Hazırlık ortamında genellikle ya anonimleştirilmiş üretim verileri ya da özenle seçilmiş gerçekçi bir veri seti bulunur. Gerçek şekiller, gerçek uzunluklar, gerçek uç durumlar, ancak isimler ve e-postalar temizlenmiştir. Tasarımlarınızın Christopher Hassan-Williamson III adlı bir müşteriyle veya altmış üç satırlık bir siparişle nasıl göründüğünü burada gerçekten görebilirsiniz. Gerçek tasarım kalite kontrolünü yapabileceğiniz tek yer burasıdır.

Üretim ortamında gerçek veriler bulunur, bu yüzden de ona müdahale etmemelisiniz. Anlık görüntülere ve gösterge panellerine bakabilirsiniz, ancak üretim ortamını asla test alanınız olarak kullanmamalısınız.

Tasarımcının Her Ortamdaki Rolü

Her ortamdaki işinizi düşünmenin en temiz yolu, kendinize her birinde farklı bir mod atamaktır.

Geliştirme ortamında, bir takım üyesisiniz. Ekran paylaşımı üzerinden hızlı kontroller yaparsınız, mühendisin tasarımı anladığından emin olursunuz, büyük yapısal sorunları erken yakalarsınız. Geliştirme ortamında hiçbir şeyi kırmızı çizgiyle işaretlemezsiniz çünkü mühendis hala geliştirme aşamasındadır.

Hazırlık ortamında, tasarım kalite güvencecisisiniz. Figma dosyasıyla karşılaştırırsınız, durumları kontrol edersiniz, eksiklik listesini yazarsınız. Ciddi incelemelerinizi burada yaparsınız, yapılandırılmış yorumlar bırakırsınız ve değişikliği onaylar veya engellersiniz. Hazırlık ortamı sizin alanınızdır.

Üretimde, bir misafirsiniz. Gönderilen değişikliği doğrularsınız, ekran görüntüsü alırsınız, işiniz buysa analizleri izlersiniz. Üretimde etrafta dolaşıp test yapmaz veya "sadece bir şeyi hızlıca dene" gibi şeyler yapmazsınız.

Bu üç modu aklınızda tutun ve mühendislik ekibinizin birlikte çalıştığı en kolay tasarımcılardan biri olacaksınız.

Tasarımcıların Sürekli Yaptığı Hatalar

Tasarımcıların bunların hepsini yaptığını gördüm. Bazılarını ben de yaptım. Hiçbiri dünyanın sonu değil, ancak hepsi ekibinizi yavaşlatıyor ve mühendislik itibarını zedeliyor.

Klasikler:

• Müşteriye geliştirme URL'si göndermek. Geliştirme birinin dizüstü bilgisayarında olduğundan, müşteri bağlantıya tıklıyor, bağlantı hatası alıyor ve "Hatta bir şey mi gönderiyorsunuz?" diye soruyor.

• Eski bir CDN önbelleğinden "canlı hata" bildirmek. Altı saat önce önbelleğe alınmış bir sürüme bakıyorsunuz ve sert bir yenileme bunu düzeltiyor.

Bir sonraki grup, nerede neyin canlı olduğu konusundaki karışıklıktan kaynaklanıyor:

• Hazırda test ortamında düzeltilmiş bir şey için hata bildirmek. Üretim ortamına baktınız, eski sürümü gördünüz ve panik içinde Slack hatası bildirdiniz. Düzeltme bir haftadır test ortamında mevcut.

• Önizleme bağlantısı istememek. Mühendis, dağıtım gerçekleştiği anda önizleme URL'sini paylaşabilirdi, ancak siz üç gün boyunca test ortamına geçmesini bekliyorsunuz.

Son iki madde ise test ortamı ile üretim ortamı arasındaki çizgiyi korumakla ilgili:

• Bir şeyi "test etmek" için üretim ortamına tıklamak. Artık gerçek sonuçları olan gerçek bir kullanıcısınız, bu yüzden durun.

• Dağıtım günlüğünü kontrol etmek yerine "Bu henüz yayında mı?" diye sormak. Çoğu ekip, her dağıtımı yayınlayan bir Slack kanalına sahiptir, bu yüzden onu yer imlerinize ekleyin.

Bunların her biri, var olduğunu bildiğiniz anda tek satırlık bir düzeltmeyle çözülebilir. Hiçbiri aptalca değil. Sadece size kimsenin söylemediği şeyler.

İhtiyacınız Olanı Nasıl İsteyebilirsiniz

Hataların diğer yüzü ise görgü kurallarıdır. Ortamlar etrafındaki tasarımcı-mühendis iletişimi çoğunlukla spesifik olmakla ilgilidir. Belirsiz istekler zaman kaybına neden olur, spesifik istekler ise hiçbir şeye mal olmaz.

Kötü: "Hey, yeni kart tasarımını görebileceğim bir yere yükleyebilir misin?"

İyi: "Hey, kart tasarım dalını yükleyip hazır olduğunda önizleme URL'sini bana gönderebilir misin?"

Kötü: "Ana sayfa güncellemesi henüz yayında mı?"

İyi: "PR 412 henüz üretimde mi yoksa hala test aşamasında mı?"

Kötü: "Canlı sitede bir şeyler bozuk görünüyor."

İyi: "Üretimde, /pricing sayfasındaki fiyatlandırma kartında alt kenarlık eksik. Sayfayı yeniden yükledim, hala bozuk. Ekran görüntüsü ektedir."

Her örnekte aynı kalıp kullanılır. Ortamı adlandırın, değişikliği adlandırın, kanıt sunun. Mühendisler, bu tür isteklerde bulunan tasarımcılar için dağları yerinden oynatacaklardır. Bunu yapmayanlara ise sessizce kızacaklardır.

Özellik Bayrakları: Üretim İçinde Test Ortamı

Geliştirme/test/üretim modelini faydalı bir şekilde kıran dördüncü bir kavram daha var: özellik bayrakları. Özellik bayrağı, kodda "bu yeni özelliği X kullanıcısına göster, Y kullanıcısına gösterme" diyen bir anahtardır. Ekipler, kodu üretime gönderirken yeni özelliği yalnızca küçük bir kullanıcı grubuna, genellikle sadece şirket içi personele göstermek için bunları kullanır.

LaunchDarkly, Statsig, ConfigCat ve Vercel'in kendi bayrakları gibi araçlar bunu yapar. Yeni tasarım teknik olarak üretimde canlıdır, ancak yalnızca şirket içi bayrağı kullananlar bunu görür. Diğer herkes eski sürümü görür.

Bu sizin için önemlidir çünkü "bu canlı mı?" sorusunun cevabı daha belirsiz hale gelir. Kod canlı olabilir, ancak özellik olmayabilir, bu nedenle mühendisten hesabınız için bayrağı değiştirmesini istemeniz gerekebilir. Ya da "gönderildi, sadece bir bayrağın arkasında, salı günü herkes için açacağız" diyebilirler.

Özellik bayrakları, olgun ekiplerin herkesi rahatsız etmeden sürekli olarak kod göndermesinin yoludur. Ayrıca, gerçek kullanıcılarla, gerçek üretim verileri üzerinde, düşük riskle, aşama incelemesinin eşdeğerini yapmanızı sağlar.

Her Ortamın Ekip Hakkında Size Öğrettikleri

Bir ekibin bu üç ortamı nasıl ele aldığı, mühendislik olgunluğu hakkında neredeyse her şeyi anlatır. Bunu yeni bir müşteri veya rol için hızlı bir okuma olarak kullanın.

Staging'i olmayan bir ekip hızlı hareket ediyor ve dua ediyor. Sonunda bir müşteriye mal olacak bir hatayla karşılaşacaklar ve ardından staging'i kuracaklar.

Staging'i olan ancak önizleme dağıtımları olmayan bir ekip ortada yer alıyor. İncelemeler yavaş, "tamamlandı"dan "tasarımcı bakabilir"e kadar olan döngü günlerce sürüyor, çok zaman bekleyerek geçireceksiniz.

Önizleme dağıtımları, gerçek bir staging, izlenen üretim ve özellik bayrakları olan bir ekip, istediğiniz seviyede çalışıyor. Geri bildirim döngüleri kısa, hatalar erken yakalanıyor, lansman gününde kimse panik yapmıyor. Orada çalıştıktan sonra, diğer seviyeler yorucu geliyor.

Üç ortam, üç hedef kitle, üç veri seti, bunları birbirine bağlayan bir yaşam döngüsü. Tüm konsept bu. Geri kalan her şey üstüne eklenen araçlardır.

Kod dağıtmayı veya bir Vercel hesabını yönetmeyi bilmenize gerek yok. Sadece hangi ortama baktığınızı, orada neler yapmanıza izin verildiğini ve doğru URL'yi nasıl isteyeceğinizi bilmeniz yeterli. Bunu yaparsanız, mühendislerinizin gerçekten birlikte çalışmak isteyeceği tasarımcı siz olacaksınız.

Dağıtım günlüğünü yer imlerinize ekleyin, önizleme bağlantısını isteyin ve üretim ortamına dokunmayı bırakın.