Leslie Cohn-Wein ile Çarpıcı Podcast 29. Bölüm: Dogfood The Jamstack'i Nasıl Netlify Ediyor?

Bu bölümde, Jamstack'i Netlify'da test etmenin nasıl bir şey olduğunu soruyoruz. Bir uygulamanın tamamını bir CDN'ye dağıtabilir misiniz? Drew McLellan, öğrenmek için Netlify Personel Mühendisi Leslie Cohn-Wein ile konuşuyor.

Notları göster

• Leslie'nin kişisel sitesi
• Twitter'da Leslie
• netleştir

Haftalık güncelleme

• React- Three-Fiber Kullanarak React Ve Three.js'ye Dalış
  Fortune Ikechi tarafından yazıldı
• E-Ticaret Kullanıcı Arayüzü Tasarımı İçin En İyi Uygulamalar
  Suzanne Scacca'nın yazdığı
• Auth0 ile React Uygulamalarının Doğrulanması
  Nefe Emadamerho-Atori tarafından yazılmıştır.
• Uzmanlardan: COVID-19 Sırasında Küresel Dijital Erişilebilirlik Gelişmeleri
  Robin Christopherson tarafından yazıldı.
• Vue 3'teki Yenilikler Neler?
  Timi Omoyeni'nin yazdığı

Transcript

Drew McLellan: Aslen Austin'den ödüllü bir ön uç uzmanı, ancak şimdi New York'ta bir görev aracılığıyla Dallas, Teksas'ta yaşıyor. Ajanslar için çalıştığı süre boyunca Nintendo, WorldPride ve Jerry Seinfeld gibi müşteriler için siteler kurdu. Şu anda Netlify'da personel ön uç mühendisi ve diğer şeylerin yanı sıra müşterilerin hizmetlerini ve dağıtımlarını yönetmek için kullandıkları uygulamayı oluşturmaya çalışıyor. Yani, onun başarılı bir ön uç mühendisi olduğunu biliyoruz, ama biliyor muydunuz, New York'ta yaşarken, arka arkaya üç yıl kırmızı biberli aşçı yardımcısı olarak görev yaptı. Ve bu gerçekten doğru. Ezici dostlarım, lütfen Leslie Cohn-Wein'e hoş geldiniz. Merhaba, Leslie. Nasılsınız?

Leslie Cohn-Wein: Eziyorum.

Drew: Bugün sizinle Netlify'ın bir nevi kendi köpek mamasını nasıl yediği hakkında konuşmak istedim, konu Jamstack üzerine inşa etmeye geldiğinde bu büyüleyici ifadeyi kullanmak. Birkaç ay öncesine kadar Netlify'da aynı ekipte birlikte çalıştığımızı söyleyerek bunu biraz bağlama oturtmalıyım. Ve oraya gittiğimde, geliştirici olarak 20 yıl sonra bile geliştirme süreci bana gerçekten yabancıydı. Bunun gerçekten büyüleyici olduğunu ve daha geniş bir kitleyle biraz keşfetmeye değer olduğunu düşündüm. Muhtemelen bundan bahsettiğimizi belirtmeliyim çünkü gerçekten ilginç bir vaka çalışması yapıyor ve Netlify için sponsorlu büyük bir reklam değil. Herkes Vercel'e bakmalı. Ama bence bu konuyu tartışarak öğrenilebilecek çok değerli şeyler var, özellikle de Jamstack açısından. Çünkü Netlify, Jamstack yaklaşımının gerçekten büyük bir savunucusu ve hizmet bir nevi müşteriye sunuluyor ve Jamstack projeleri oluşturma fikri etrafında inşa ediliyor. Ancak hizmet de bu ilkelerin kendisi kullanılarak oluşturulmuştur. değil mi?

Leslie: Öyle, evet. Pek çok insan bu Jamstack mimarisini statik siteler olarak düşünür, ancak Netlify ön ucu ile bir Jamstack uygulaması oluşturmanın ne anlama geldiğini gerçekten test ediyoruz. Netlify'ı Netlify'a dağıttığımız tam bir Jamstack uygulaması olan bir React uygulaması olduğu için… Evet, gerçekten deniyoruz ve mümkün olanın sınırlarını zorluyoruz.

Drew: Bence bazen Jamstack'in dediğiniz gibi sadece statik siteler için harika olduğu fikri var ve bir e-posta adresine bir form göndermek istiyorsanız API yönü devreye giriyor ve bunun gibi kolay bir şey yapabilirsiniz, ancak siz muhtemelen bu şekilde bütün bir web uygulaması oluşturabilir. Ama bunu yapıyorsun değil mi?

Leslie: Evet, kesinlikle. Özellikle app.netlify.com'da oturum açarsanız sizi ne göreceğinizden bahseden uygulamamız… tarafından desteklenmektedir… dahili bir REST API'miz var, ancak dediğim gibi ön uç tamamen Jamstack. Yani kendi derleme adımımız var, uygulamayı uygulamada oluştururken izliyoruz ve kendi sistemimize dağıtıyoruz.

Drew: Yani, bir arka uç süreci söz konusu olduğunda ve her zaman bir tür arka uç süreci olacaksa, bilirsiniz, kalıcı veriler veya Netlify'ın durumunda, bir dağıtımla başlayarak veya neye sahipseniz, o arka uç sadece daha sonra ön uç tarafından tüketilebilecek bir dizi API olarak inşa ediliyor mu?

Leslie: Evet, bu işi nasıl yapabileceğinize dair birkaç farklı model var. Çoğu durumda, uygulamamızda React ile istemci tarafı getirmeyi kullanırız, değil mi? Bu nedenle, uygulamanın bir tür statik kabuğunu sunarız ve ardından istek zamanında dahili REST API'mizden kullanıcının bilgilerini alırız. Jamstack ilginç çünkü önceden oluşturabileceğiniz bazı şeyler var ve elimizden geldiğince buna güvenmeye çalışıyoruz. Daha sonra bazı daha dinamik verilerden bahsederken, en yeni verileri aldığımızdan emin olmak için bu istemci tarafı getirmeyi kullanacağız.

Drew: Uygulama üzerinde çalışmaya başladığımda, özellikle harici API'ler ve diğer şeylerle etkileşim söz konusu olduğunda, ön uçta ne kadar başarılı olunduğunun beni şaşırttığını düşünüyorum. Netlify'ın Git sağlayıcınızla etkileşime girdiğinde, GitHub'a gittiğini ve bir depo listesi aldığını biliyorum, bunların hepsi tarayıcınız ve GitHub arasında oluyor. Ve belki de... istek üzerine bazı sırlar koyan sunucusuz bir işlevden geçmek veya bunun gibi hafif bir şey dışında, bunların çoğu sadece Jamstack-y türünde oluyor. Netlify türünde bir çekirdek arka uç altyapısından geçmiyor. Yani, bu oldukça büyüleyici. Bu, küçük şeyler yapmak için birkaç API çağrısı içeren statik bir sitenin gerçekten çok ötesine geçiyor. Tarayıcıda uygulanan gerçek çekirdek işlevsellik bu, değil mi?

Leslie: Kesinlikle. Ön uç geliştirici mühendisinin ne olduğu kavramını gerçekten zorluyor, değil mi? Ve bir ön uç mühendisi olarak beni daha iyi olmaya ve bu türler hakkında daha fazla düşünmeye iten bir şey… API katmanı, ki bu geleneksel olarak pek yakın olmadığım bir şey. Daha çok kullanıcı arayüzü, renkler ve tasarım sistemlerinde çalışıyorum ve bu yüzden gerçekten… Aslında bir Jamstack uygulaması üzerinde geniş ölçekte çalışmanın beni daha iyi bir geliştirici olmaya ittiğini keşfettim.

Drew: Bir ön uç geliştirici olmak, CSS'yi baştan sona bilmemek, bunun bir parçası olsa da. HTML'yi arka arkaya bilmek değil, ama bunun bir parçası olsa da. Ayrıca, geleneksel olarak bir arka uç mühendisinin koruma alanı olan bu bölgeye sapıyor, ki bu oldukça ilginç. Netlify, aşağıdakiler için yeni sunucu tarafı işleme kullanıyor mu?

Leslie: Bildiğimden değil.

Drew: Yani, her şey tam anlamıyla yapılır, sizin dediğiniz gibi, bir kabuğa hizmet edersiniz ve ardından hepsini bir şekilde doldurmak için farklı API uç noktalarına geri gelen isteklerle doldurulur.

Leslie: Aynen.

Drew: Ve bunun bir React uygulaması olduğunu mu söylüyorsun?

Leslie: Evet. Evet. Tepki. Şu anda React Redux kullanıyoruz ve şu anda PostCSS'yiz, ancak CSS mimarimizi de deniyoruz.

Drew: Hepimiz değil miyiz? Yani uygulamayı React'te oluşturuyorsunuz ve ardından Netlify'da mı dağıtıyorsunuz?

Leslie: Evet. Belki de tüm bu sürecin en sevdiğim yanı, Netlify aracılığıyla elde ettiğimiz Dağıtım Önizlemelerinin büyüsüdür. Yani olan şu ki, siz… GitHub'da çalışıyorsunuz, PR'nizi artırıyorsunuz. Böylece, PR'nizi GitHub'da açarsınız ve bu, uygulamanın Dağıtım Önizlemenizin bir yapısını otomatik olarak oluşturacaktır. Bu nedenle, her şeyin olması gerektiği gibi çalıştığından emin olmak için test etmek için aslında uygulamanın Dağıtım Önizlemelerini kullanıyoruz. Testlerimizi çalıştırıyoruz. Kod incelemesi sırasında manuel olarak doğrulamak için kullandığımız şey budur. Bu nedenle, doğrudan GitHub'dan kurulan tüm bu sürekli dağıtımlara sahibiz.

Leslie: Ve kurduğumuz diğer harika şeylerden biri, aslında uygulamamızın yaşadığı aynı depodan çeken birkaç farklı Netlify sitemizin olması. Yani, hem uygulamamız hem de uygulama için UI bileşenlerine sahip bir Storybook örneğimiz var. Yani, hem uygulamamızın kendisine hem de Storybook UI bileşenlerine sahibiz ve temelde Storybook UI'mizi gösteren bir Netlify sitemize sahibiz. Ayrıca bir web paketi paket analizörü çalıştıran üçüncü bir sitemiz de var. Bu, size bir ağaç haritası, tüm uygulama paketlerinin görselleştirilmesini sağlayan görsel bir kullanıcı arayüzüdür ve boyutlarını bir şekilde ölçebiliriz ve bu, bizim için bir tür iki kez kontrol etmemiz için bir hatırlatmadır. Uygulamanın her dağıtımı sona erdiğinde, paket boyutumuzla garip bir şey yapmadığımızı kontrol edebilir ve emin olabiliriz. Böylece, bu sitelerin üçü de uygulamanın tek bir Çekme İsteğinde oluşturulur. Böylece, hem uygulama Storybook'un hem de kontrol etmemiz için o uygulama profilinin önizlemesine, esasen Dağıtım Önizlemelerinize bağlantılar alacaksınız.

Drew: Ve Dağıtım Önizlemeleri ile, bu aslında bir nevi hazırlama ortamınız oluyor, değil mi?

Leslie: Aynen. Gerçekten geleneksel bir hazırlama ortamı çalıştırmıyoruz, çünkü o birleştirme düğmesine bastığımızda ve ana uygulamamızda ana şubemizin resmi yapısını başlattığımızda, Dağıtım Önizlemelerimizin esasen hayata geçirileceğine gerçekten güveniyoruz. Bu nedenle, hazırlama ortamı olarak Dağıtım Önizlemelerine güvenebileceğimizi seviyorum. Üretimle eşleşeceğine gerçekten güveniyoruz. Bunu tüm üretim değişkenleriyle birlikte oluşturuyoruz, her şey... ortam değişkenleri, tüm bu şeyler Dağıtım Önizlemesinde yerleşik hale geliyor. Yani, neredeyse endişesiz bir durum gibi. Dağıtım Önizlemeniz çalıştığı sürece uygulamanın da çalışacağını bilirsiniz.

Drew: Ve sanırım, bir organizasyon olarak, Dağıtım Önizlemeniz yayınlananla eşleşmiyorsa, bu Netlify'ın çözmek istediği bir hizmet sorunudur. Yani, aslında bu açıdan oldukça güzel çalışıyor. Bir Dağıtım Önizlemesi'ni incelediniz, her şey harika görünüyor, PR birleşiyor. O zaman ne olacak?

Leslie: Yani, Netlify tüm sürekli dağıtımımızı çalıştırdığı için, esasen hepsini bağladık, böylece ana şubemizde herhangi bir birleştirme otomatik olarak uygulama ile resmi bir üretim dağıtımını başlatacak. Bu nedenle, tipik olarak, kendi PR'nizi birleştiren geliştiriciyseniz, gerçek duruma gelirsiniz… emin olmalısınız, sekmelerinizi iki kez kontrol edin, çünkü uygulamanın Açık ve uygulamanın bir Dağıtım Önizlemesi varsa, emin olmalısınız… genellikle gerçek uygulamada takip etmek istersiniz. Yani, sekmenizi kontrol etmelisiniz. Ancak, evet, uygulamada, genellikle girersiniz, az önce başlattığınız birleştirme için derleme günlüklerini izleyebilirsiniz, yani her şey otomatiktir. Ardından, bu derleme günlükleri tamamlanır tamamlanmaz ve site yayına girer girmez, tek yapmanız gereken tarayıcı pencerenizi yenilemek ve az önce dağıttığınız her şeyin uygulamada güncellenmesi gerektiğini göreceksiniz.

Drew: Diyelim ki bir sorun yayına girdikten sonra yakaladınız, o zaman ne yaparsınız?

Leslie: Bu çok güzel bir soru. Ve belki de Netlify'ı kullanmayla ilgili en sevdiğim şeylerden biri, Netlify'da çalışmadan önce bile, bu benim için biraz sihir gibiydi, çünkü Netlify, bizim dediğimiz, geri alma dediğimiz bir tür pişti. Bu nedenle, aslında Netlify'daki her dağıtım… bu Jamstack mimarisini kullandığımız için her dağıtım atomiktir. Yani bu, bir sitede şimdiye kadar yaptığınız her tür dağıtımın tam geçmişine sahip olduğunuz ve bunlardan herhangi birine anında geri dönebileceğiniz anlamına geliyor. Bu nedenle, yanlışlıkla bir hatayı dağıtırsak veya bir şey bozulursa, genellikle yaptığımız ilk şey, aslında bu sürekli entegrasyonu durdurmaktır. Bu yüzden içeri gireceğiz ve Netlify kullanıcı arayüzünde "Otomatik yayınlamayı durdur" dediğiniz sadece bir düğme ve bunun yapacağı şey GitHub ile olan bağlantıyı durdurmak. Yani, eğer takım arkadaşım aniden PR'larını birleştiriyorsa, hatayı yeniden tanıtmayacağız, böyle bir şey olmayacak.

Leslie: Yani, tüm bu otomatik dağıtımları durduruyoruz. Ve sonra tek yapmam gereken dağıtım listeme geri dönmek ve çalışan son dağıtımı bulmak, "Bunu yayınla" yazan bir düğmeye daha basmak ve yayına girmek. Yani, bu gerçekten geriye dönüp koda bakabilmek ve gerçekte ne olduğunu anlayabilmek için bu baskıyı ortadan kaldırıyor. Bazen bu, ana dalınızda bir Git dönüşü yapmak ve ana dalı olması gereken yere geri getirmek anlamına gelir. Ve bazen bu bir düzeltmedir veya bir şubeye gidersiniz ve onu düzeltirsiniz ve Git'te geri dönme konusunda gerçekten endişelenmenize bile gerek yoktur. Ardından, geri dönmeye hazır olduğunuzda, uygulamanın Dağıtım Önizlemenizde her şeyin çalıştığından emin olur ve tüm bunları yeniden sıfırlayabilirsiniz. Bu otomatik dağıtımlara başlar başlamaz, temelde işinize geri dönersiniz.

Drew: Yani, burada bir sorun tespit ettim.

Leslie: Ah ah.

Drew: Değişiklikleri Netlify uygulamasında dağıtmak için Netlify'ı kullanıyorsunuz. Ya dağıttığınız hata geri dönmenizi engellerse? O zaman ne yapacaksın?

Leslie: Kabuslar görüyorum. Hayır. Aslında, bununla başa çıkmanın birkaç yolu var. Bu nedenle, uygulamayı kaldırırsak ve bu süreçten geçmek için kullanıcı arayüzünü kullanamazsak, Dağıtım Önizlemelerimiz aslında üretim API'mize karşı çalışır. Bunun anlamı, uygulama çalışmıyor olsa bile, hala o atomik dağıtımlara sahibiz. Bu nedenle, GitHub'dan, belki de eski veya yeni bir PR'den bir bağlantınız varsa ve bu Dağıtım Önizleme URL'sine sahipseniz, aslında uygulamanın Dağıtım Önizlemesi'ne erişebilir ve ihtiyacınız olan değişikliği yapabilir, geri dönüp daha eski bir dağıtımı yayınlayabilirsiniz. Dağıtım Önizlemesinden. Ve hala üretim API'mize çarpıyor, bu yüzden uygulamayı etkilemeye devam edecek ve ardından bu, uygulamayı geri getirecek. Orada patlayan bir beyin emojisi gibi, ama bunu yapmanın bir yolu. Ayrıca bazı arka uç sistemlerimizden daha eski bir dağıtım yayınlayabiliriz. Arka uç mühendislerimizin bunu bizim için yayınlamasını sağlayabiliriz. Veya Git'i her zaman geri almak ve bunu yukarı itmek için kullanabilirsiniz, ancak bu biraz korkutucu çünkü ne yaptığınızı izleyemezsiniz.

Drew: Sanırım bu durumu yönetmek için çok açık bir zihne ihtiyacın var.

Leslie: Evet.

Drew: Ama tamamen kurtarılabilir, kulağa öyle geliyor.

Leslie: Evet. Peki, ve çalışan dağıtımınızı yayınladıktan sonra, tüm baskı ortadan kalkar. Bu gerçekten en güzel kısım. Ve bunu ajanslarda da buldum. Geri dönebilmek gerçekten bir cankurtaran oldu… Ayrıca yeni değişiklikleri yayınlama konusunda sizi daha az endişelendiriyor. Bir şeyi kırarsanız, onu geri döndürmek bir saniye sürer, bu da hızlı hareket türüne çok iyi uyum sağlar ve bir şeyleri modelden çıkarır.

Duru: Kesinlikle. Bence tipik olarak bu tür bir iş akışı, gerçekten küçük değişikliklerle uğraşırken en iyi sonucu verir. Demek istediğim, ideal olarak bir şube oluşturmak, küçük bir değişiklik uygulamak, bir PR yükseltmek ve sonra bunu mümkün olduğunca çabuk birleştirmek istersiniz. Açıkça ince ayarlar, hata düzeltmeleri ve küçük şeyler için iyi çalışıyor, ancak bu özelliğin kullanıma hazır hale gelmesi haftalar hatta aylar alabileceği zaman, ana özellik çalışması için o kadar iyi çalışmıyor. Bu tür bir süreci nasıl yönetiyorsunuz?

Leslie: Evet, bu harika bir soru. Bu nedenle, son zamanlarda özellik bayraklarını biraz daha fazla kullanmaya başladık. Bunu nasıl yaptığımız hakkında biraz daha konuşmadan önce, eskiden ne yaptığımızdan bahsedeceğim. Bu nedenle, özellik bayraklarını kullanmadan önce, herkesin uzun süredir devam eden özellik dalı fikrine aşina olduğunu düşünüyorum. Hepimiz onlardan nefret ediyoruz, değil mi? Ancak daha küçük PR'larımız üzerinde çalışırdık. Kod incelemesinden sonra bunların her birini, daha uzun süre çalışan bu özellik dalında birleştireceğiz. Böylece, temel olarak tüm yeni özelliğinizi tek bir yerde toplarsınız, bu yeni özelliği test edebileceğiniz bir Dağıtım Önizlemeniz olabilir. Bazen bu model, diğer ekipler arasında koordineli dağıtımlar gerektiriyordu. Bu nedenle, "Tamam, bu özellik dalı, onu birleştirmeye ve yayınlamaya hazırız" demeye hazır olduğumuzda, bu bazen "Tamam, arka ucun değişikliklerini zaten dağıttığından emin olmalısınız" anlamına geliyordu. Özelliğimizde yaptığımız API çalışması kullanıma hazır. Doküman sitemizde, özellikle aynı anda yayınlanması gereken dokümanlar varsa, aynı anda koordine etmeniz ve düğmelere basmanız gerekir.

Leslie: Bu model... bizim işimize yaradı ama haklısın, belki de en pürüzsüz olanı değildi. Netlify'daki kurucu ortağımız ve CEO'muz Matt Biilmann, geçen yıl Jamstack Conf London'da sahnede bu süreci kullanarak analitik özelliğimizi başlattı. Bu nedenle, temel olarak yeni analitik özelliğinin Dağıtım Önizlemesini almak ve onu sahnede canlı olarak yayınlamak için kilit konuşlandırma özelliğimizi kullandı. Yani, bu oldukça güzeldi.

Leslie: Ama dediğin gibi, bu... kendine güvenin biraz daha az. Bu Çekme İsteğinde her şey hala bir şekilde gizlidir. Biraz hantal hale gelir. Birinin genellikle oldukça büyük olan bu son Çekme Talebini onaylaması gerekir. Bu biraz ezici. Bu nedenle, günümüzde çoğunlukla özellik bayrakları kullanıyoruz. LaunchDarkly adlı bir hizmet kullanıyoruz; bu, temel olarak yeni özellik kullanıcı arabirimimizi bu bayraklarla sarmamıza olanak tanıyor, böylece kullanıcı arabirimi müşterilerin görmesini istediğimiz bir şey olmasa bile kodu sürekli olarak birleştirmeye devam edebiliyoruz. Bu nedenle, üretim ortamında özellik bayrağınızın kapalı olduğundan emin olun, kodu dağıtabilir, birleştirebiliriz ve hiç kimse… genel bir kullanıcı olduğunuzu varsayarsak, bu yeni kullanıcı arayüzünü görmeyeceksiniz.

Drew: Yani, bir özellik bayrağı temelde, "Bu özellik etkinse, bu yeni kodu kullanın, yoksa bu eski kodu kullanın" yazan koddaki bir anahtar gibidir.

Leslie: Aynen.

Drew: Bu, tüm bu çatallar yerindeyken bir tür dağınık kod tabanı elde ettiğiniz anlamına mı geliyor? Bununla nasıl başa çıkıyorsun?

Leslie: Evet, sanırım bu… özellik bayraklarını kullanan herhangi biri muhtemelen bu tür savaşlara alışmıştır, özellik bayraklarını ne zaman temizlersiniz? Onları orada ne kadar süre bırakırsın? Önemli bir özelliğin yayınlanmasından yaklaşık iki hafta sonra, hatırlatıcılarımız var. Neyse ki, LaunchDarkly aslında yakın zamanda Slack'i bilgilendirecek bir özellik kurdu. Böylece, Slack'e bağlayabilirsiniz ve o size şunu söyleyecektir: “Hey, özellik bayrağınız… İki haftadır prodüksiyonda canlı yayındasınız. Bayrağınızı kodda temizlediğinizden emin olmanın zamanı geldi.”

Leslie: Yani, deniyoruz ve onu oldukça hızlı bir şekilde temizliyoruz, ama aradaki bu süre içinde, bayrağın hala orada olduğunu bilmek güzel. Özelliği yayınlamış olsanız bile, bu, tekrar, tek bir tıklamayla içeri girip o bayrağı tekrar kapatabileceğiniz anlamına gelir, eğer ortaya çıkan bir şey varsa, bir hata vardır. Bu yüzden, herhangi bir önemli sorun olmadığından emin olmak için, özellik gerçekten pişerken, insanlar buna alışırken, onları bir süreliğine bırakmayı seviyoruz. Ama sonra koda geri dönmeye çalışırız ve bu biraz temizlemedir, bu nedenle ideal bir süreç değildir, ancak genellikle bayrağı kaldırmak çok uzun sürmez, sadece birkaç satır kod siliyorsunuz.

Drew: Yani, bir özellik bayrağını uygulamaya koymanın en basit yaklaşımı, uygulamanızda "Bu özellik açık veya kapalı" diyen bir yapılandırma değişkeni gibi olabilir, ancak o zaman, bundan emin olmak için bir yola ihtiyacınız var. doğru insanlar için açık ve doğru insanlar için kapalı. Ve sanırım LaunchDarkly gibi bir hizmet burada devreye giriyor, çünkü bunu gerektiriyor… Yani, temelde bir değişkeni açıp kapatan şeyi aşırı bir seviyeye taşıyor, değil mi?

Leslie: Evet. Evet. Aynen öyle. Yani, LaunchDarkly olmadan bile, temel olarak kendi başımıza yönettiğimiz bir yapılandırma değişkeni kurmamızın yolları var. LaunchDarkly ile ilgili sevdiğim şeylerden biri de farklı ortamların olması. Yani, Yapabileceğimiz şey, Dağıtım Önizlemelerimiz için esasen bir özellik bayrağı açmaktır. Böylece, Netlify'da dahili olarak uygulamanın Dağıtım Önizlemesi'ni görüntüleyen herkes yeni özelliğe erişebilir, onu test edebilir, ancak daha sonra, üretimde yayına girer girmez bu bayrak devre dışı kalır. Yani, çok az şey var… yine, sekmenizi kontrol etmeniz ve hangi segmentte bulunduğunuzun farkında olduğunuzdan emin olmanız gerekiyor, çünkü kendinizi şaşırtmak ve böyle bir şey başlattığınızı düşünmek istemiyorsunuz. yapmadın, orada biraz dikkatli olmalısın. Ancak genel olarak oldukça iyi çalışıyor ve LaunchDarkly, bu seçici sunumları da yapmanıza izin veriyor. Böylece, bir özelliği kod tabanınızın belirli bir yüzdesine veya belirli bir kullanıcı segmentine, belirli bir plan tipine veya belirli bir kullanıcı tipine sahip kişilere sunabilirsiniz. Böylece, kimi serbest bıraktığınız üzerinde çok daha fazla kontrol sahibi olmanızı sağlar.

Duru: Evet. Sanırım, özellikle bir sorunu çözmeyi umduğunuz yeni özellikler veya özellikler söz konusu olduğunda, bu gerçekten güçlü olabilir. Belki bir özelliği daha anlaşılır hale getirmek için geliştiriyorsunuzdur, belki kullanıcıların %10'u ile deneyebilir ve aynı sorunları yaşayıp yaşamadıklarını görebilirsiniz ve…

Leslie: Aynen. Geri bildirim almanın da harika bir yolu, evet.

Drew: Sanırım kendi çözümünüzü kullanmak yerine LaunchDarkly'yi bu şekilde kullanmak Jamstack yaklaşımının bir başka yönü, değil mi? Bu sadece, bunu nasıl uygulayacağınız ve bunu nasıl geliştireceğiniz ve nasıl sürdüreceğiniz ve bunu nasıl koruyacağınız konusunda endişelenmenize gerek kalmadan size bu işlevselliği sağlayan bir API kullanmaktır, böylece onu dış kaynaktan temin edebilirsiniz, “Doğru, biz bu API'yi kullanacak ve diğer her şey halledilecek."

Leslie: Evet. Evet, aynen.

Drew: Yani, bu yaklaşım, esasen üretime küçük parça parça yeni özellikler eklemenizi sağlıyor, ancak bunlar bir nevi bayrağın arkasına gizlenmiş durumda. Ve sonra her şey gitmeye hazır olduğunda, sadece bayrağı çevirebilir ve bir şeyler ters giderse hızlıca tekrar değiştirebilirsiniz.

Leslie: Evet, kesinlikle. Lansmanlarımızı biraz daha az heyecanlı hale getiriyor. Eskiden bu büyük düğmelere basıyordunuz ve birleştirilen tüm bu kodlar var ve derleme günlüklerinizi izliyorsunuz ve bu beklenti anı. Ve şimdi bir Zoom çağrısına atlıyorsunuz, bir düğmeye basıyorsunuz ve bu canlı.

Duru: Evet. Sanırım son özellik lansmanı, bir Netlify üzerinde çalıştım, bu yaklaşımı kullandık. Ve bütün bir ekip için haftalarca çalışmıştı ve çıkışı koordine etmek için bir Zoom çağrısında bulunduk ve herkes parçalarının hazır olduğunu onayladı. Sonra özellik bayrağını çevirdim ve tüm kullanıcılar için açtım, hepsi bu kadar.

Leslie: Bitti.

Drew: Ve birkaç dakika içinde bitti ve gerçekten antiklimaktikti.

Leslie: Evet, bu biraz üzücü.

Drew: Terli avuç içi yoktu, hiçbir şey yoktu, tabii ki tam olarak istediğin şey bu, değil mi? Bir şeyi herkes için açmak çok da önemli değilse, sağlam bir sürece sahip olduğunuzu bu şekilde bilirsiniz.

Leslie: Aynen. Ve tekrar geri almanız gerekiyorsa, bu kadar basit, o tek tıklama. Bu baskının, kaygının bir kısmını hafifletir.

Drew: Yani, muhtemelen, demek istediğim, tüm değişiklikler sadece ön uç değişiklikleri olmayacak. Bazen arka uç değişiklikleri olacak ve muhtemelen çoğu arka uç sisteminde de kendi özellik bayraklarına sahip olacaklar. Yani, dokümanlardan da bahsettiniz. Tüm bunları birlikte koordine etmenin bir yolu var mı? Herkes aynı anda bayraklarını mı çeviriyor? Ya da bu nasıl çalışıyor?

Leslie: Evet. Bu, şu anda Netlify'daki ekipler arasında aktif olarak üzerinde çalıştığımız bir alandır ve belki de her şeyi LaunchDarkly'de tüm sistemlerimizin kullandığı tek bir bayrağa bağlamamıza izin verecek bir çözüm için çalışıyoruz. , tüm kod tabanlarımız kullanıyor. Bu nedenle, ideal bir dünyada, bir bayrağı çevirebilir ve "Tamam, bu, bir özellik bayrağına sarılmış bu yeni UI ile ön uçta tüketilen yeni API bitiş noktasında geçiş yapmaktır," diyebilirdik. ve bu yeni özellik hakkında yeni bilgiler içeren belge sitesinin bu bölümü." Ve içindeki bir bayrağı çevirirseniz, tüm bu depoları etkiler. Henüz tam olarak orada değiliz. Bunun üzerinde çalışıyoruz, ancak bunların hepsini koordineli ve çalışır hale getirip getiremeyeceğimizi görmek beni heyecanlandırıyor.

Drew: Netlify, bir hizmet olarak büyük ölçüde bu şekilde şantiyelere uyarlanmıştır. Ürünü kullanarak sizin ve ekibinizin yaptığı işler, ürün geliştirmeyi gerçekten etkiledi mi?

Leslie: Kesinlikle öyle olduğunu söyleyebilirim. Herkes her zaman senin kullanıcın olmadığını söylüyor, ki bazen senin kullanıcın olduğun zamanlar dışında çoğu zaman doğru olduğunu düşünüyorum. Netlify'da bu komik çünkü özellikle ön uç ekibindeki insanların çoğunun Netlify'ı daha önce bir ürün olarak kullanmış kişiler olduğunu düşünüyorum. Ve kesinlikle Netlify'ı Netlify'ı dağıtmak için kullandığımız için, bazı kullanıcılarımızın yaşadığını düşündüğüm zorluklarla karşılaşıyoruz. Bu nedenle, bazı açılardan, bir sorunla karşılaşırsak, bunu şirketin geri kalanına iletmeye çalışırız. Bir mühendislik görüşmesinde bundan bahsedeceğiz ya da CTO'muzu çağıracağız ve “Hey, bu mücadele ettiğimiz bir şey. Bunu bizim için ve bizimkine benzer şeyleri dağıtan tüm kullanıcılarımız için kolaylaştıracak ürüne ekleyebileceğimiz bir şey var mı?” Bu nedenle, içinde bulunmak için benzersiz bir konum, ancak ürün yol haritasının nasıl geliştirildiğini görmek eğlenceli.

Drew: Sanırım Netlify'ı Netlify'ın kendisi kadar yoğun kullanan çok az insan var.

Leslie: Evet. Evet. Bence bu doğru. Hem kurarken hem de dağıtırken Netlify'a bakıyorum, bu yüzden ona oldukça aşinayım.

Drew: Sonra hafta sonu bir yan proje üzerinde çalışıyorsun ve kendini tekrar Netlify'da buluyorsun.

Leslie: Evet. Bu aslında çok doğru. Evet. Evet. Evet kesinlikle.

Drew: Ürün yönünün ekibin yaptığı işten nasıl etkilendiğine dair herhangi bir örneğiniz var mı?

Leslie: Evet. Bu nedenle, kısa bir süre önce, Takıma Genel Bakış adını verdiğimiz uygulama için yeni bir tür açılış panosu başlattık. Yani eskiden Netlify'a giriş yaptığınızda sitenin sayfasına giderdiniz, bu da temelde sitelerinizin uzun bir listesi olurdu. İnsanlara bir bakışta pek çok önemli bilgiyi görebilecekleri, onlar için en yararlı olacak şeylere erişebilecekleri bir görev kontrol alanı biraz daha vermek istedik. Ve böylece, bu bizim inşa ettiğimiz yeni bir özellikti. İlk yinelemede, onu hızlı bir şekilde çıkarmaya çalışıyoruz, bu kullanıcı arayüzünde en son derlemelerinize bağlanan küçük bir kartımız var. Size tüm ekibinizdeki herhangi bir yapıyı gösterir, o kartta görünmesi gerekir.

Leslie: Ve ilk başta, aslında bunları yapıya bağlamamıştık… görüntüleme günlüğünün kendisine. Yani, sadece kontrol edebileceğiniz bir listeydi. Bir tür benzer görünüm elde etmek için yapılar sayfasına tıklayabilirsiniz. Ama aslında hafta sonu bir şey, kişisel bir site üzerinde çalışıyordum ve bu ekip genel bakışını açtım ve sinirlendim çünkü Netlify'a giriş yaptığımı fark ettim ve projemde gerçekleşen bu yapıya göz atmak istedim, ve sadece üzerine tıklayıp doğrudan ona ulaşamadım. Yapılar sayfasına tıklamam ve ardından tekrar tıklamam gerekiyordu. Böylece, ertesi gün işte, içeri girdim ve bu değişikliği ekledim ve bu yapıları birbirine bağladım çünkü bu beni rahatsız ediyordu. Bu, ürünü kullanarak onu geliştirmek için çok küçük bir fırsat olduğunu fark etmenin bir çeşit örneğiydi. Ve bunu aldık.

Leslie: Ama başka örneklerimiz de var. Muhtemelen biraz daha etkili. Birincisi, bu form algılama özelliğini bir şekilde ekledik. Yani, biraz arka plan, aşina değilseniz, Netlify formları, Netlify'da bir ön uç formu oluşturmanıza izin veren bir özelliktir. Ve Netlify, gönderileri yönetmenin tüm arka uç işlerini yapıyor. Formunuz için ön uçta oluşturduğunuz veritabanınız gibi. Bu, form gönderimlerini yönetmek için herhangi bir sunucu tarafı kodu veya bir sürü fazladan JavaScript yazmanız gerekmediği anlamına gelir. Gerçekten Netlify'a dağıttığınız herhangi bir site, derlemeniz gerçekleşirken, derleme botlarımız, Netlify'ın dikkat etmesi ve yönetmesi gereken bir Netlify formunuz olup olmadığını temel olarak tespit etmek için sitenizin HTML'sini dağıtım zamanında ayrıştırır. Ve yapı botunun aradığı bu form algılama, varsayılan olarak etkindir.

Leslie: Ama bunun anlamı, tahmin edebileceğiniz gibi, inşa sürenizin birazını tüketiyor çünkü botlar gidip bu ekstra adımı aramak zorunda. Yani Netlify uygulamasının kendisi, aslında kullanmıyoruz, şu anda uygulamada herhangi bir Netlify formuna sahip değiliz. Yani bu, temel olarak inşa süremize biraz ekleyen bir adımdır, ancak bunun mutlaka gerçekleşmesi gerekmez. Bu nedenle Netlify, herhangi bir kullanıcının bu form algılamasını devre dışı bırakmasına izin veren yeni bir özellik oluşturdu. Bunun anlamı, site ayarlarınızda bu ayarı kapatabilirsiniz, derleme botları aramaları gereken hiçbir şey olmadığını anlar, böylece derlemelerde biraz fazladan işlem süresinden tasarruf edersiniz.

Drew: Sanırım bu üretkenlik açısından harika çünkü işler biraz daha çabuk tamamlanıyor.

Leslie: Aynen.

Drew: Ama aynı zamanda, ölçülü bir hizmet olarak, sahip olduğunuz ödeneklerden daha fazlasını elde etmenizi sağlar.

Leslie: Evet. Kesinlikle. Bu, bazı kullanıcılarımızdan ve müşterilerimizden de duyduğumuz bir şeydi ve bizim de fark ettiğimiz bir şeydi. “Eh, kendi ürünümüzde bu ekstra adıma ihtiyacımız yok. Peki, bu özelliği kullanmıyorlarsa herkesin hayatını biraz daha kolaylaştırmak, herkesin biraz daha hızlı inşa etmesini sağlamak için tüm kullanıcılarımıza verebileceğimiz bir yol var mı?”

Drew: Bir tehlike mi var… Yani, kullanıcınız olmadığınızı söylüyorsunuz ama Netlify ile genellikle kullanıcınız oluyorsunuz. Ürünü kullandığınız yoğunlukla, onu çok hafif kullanan kullanıcıları gözden kaçırma ve her şey çok karmaşık ve çok gelişmiş hale gelme ve elde edilmesi çok zor hale gelme tehlikesi var mı? ile başladı?

Leslie: Bu harika bir soru. Ayrıca Netlify'daki kullanıcı araştırma işlevimizi ve veri bilimi işlevimizi gerçekten geliştirdik ve genel olarak onlara uygulamayı kullanma ve dağıtma deneyimimden çok daha fazla güvendiğimizi düşünüyorum. Ama bence tüm bu veriler Netlify'ı kimin kullandığına, ne tür bir kullanıcıyla konuştuğumuza dair daha iyi bir resim elde etmemizi sağlamak için bir araya geliyor. Farklı ihtiyaçları olan insanlar var. Başlangıç ​​ekiplerimizde blogları ve kişisel siteleri yöneten insanlarımız var ve aynı zamanda Netlify'ın kendisinden çok da farklı olmayan büyük pazarlama kampanyaları ve büyük web uygulamaları başlatan devasa işletmelerimiz var. Bu nedenle, kullanıcı tabanının büyüdüğünü görmek ve tüm bu kullanım durumları hakkında düşünmek ve tüm bu kullanıcılara nasıl hitap edebileceğimizi bulmak heyecan verici. Ve kesinlikle, yalnızca dahili deneyimimizi değil, bu kullanıcıların kim olduğunu anlamaya dayanmak için araştırma işlevimizden daha fazlasını kullanıyoruz.

Drew: Bana Netlify'ın uyguladığı ekran görüntüsü hizmetinden bahset Leslie? Çünkü bunu gerçekten ilginç buldum.

Leslie: Evet. Sahip olduğumuz kullanıcı arayüzünde… Netlify'da bir site dağıttığınızda, kullanıcı arayüzünde, sitenin ana sayfasının tipik olarak nasıl göründüğünü size gösteren küçük bir ekran görüntüsüne sahibiz. Bunu gündeme getirmemiz gerçekten komik, çünkü Chris Coyier'in kısa bir süre önce Serverless'taki bölümünü dinliyordum ve o onların CodePen'de de ekran görüntülerini nasıl yaptıklarından bahsediyordu ki bu aslında Netlify'ın yaptığından pek de farklı değil. Ama temel olarak, kullanıcı sitesinin o ekran görüntüsünü yakalamak için Puppeteer'ı çalıştırıyoruz ve hepsinin çalışma şekli, bir Netlify işleviyle ayarlanmış olmasıdır. Bu da yine kendi ürünümüzü test ettiğimize bir örnek. Bu nedenle, esasen, ekran görüntüsünün o görüntüsünün URL'sini döndürmek için kendi uygulamamız içinde bir Netlify işlevi olan bu bitiş noktasını kullanırız, böylece bunu uygulamada sunabiliriz.

Drew: Yani Netlify işlevleri, Netlify'ın Sunucusuz bir işlevin uygulamasıdır, değil mi? Temel olarak bir JavaScript dosyasını kaynağınızın bir parçası olarak belirlenmiş bir klasöre bıraktığınız ve ardından bu, bir bulut işlevi olarak yürütülmeye hazır hale geldiği yer.

Leslie: Evet, aynen.

Drew: Süper akıllı, değil mi?

Leslie: Evet. Bu dahice. This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you're basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it's exciting because there's so much you can do, but that can make it a little intimidating also because there's so much you can do.

Drew: I sort of find it funny how it's like… that's seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it's just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. Evet.

Drew: This sounds like a really nice way to be working, and a very modern way to we're working, but it can't be without its challenges, can it?

Leslie: Absolutely not. I think I've spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there's a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there's probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there's an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we're more familiar with or more comfortable using. So, in terms of challenges, I think it's opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there's so many different ways on there to… with the tooling that's available, to be able to attack a particular problem. At Smashing, we probably shouldn't say there's more than one way to skin a cat.

Leslie: Yikes.

Drew: What's interesting about the workflow as well, is that it's really intensively Git based, which I think suits… it's really developer friendly, isn't it? As a frontend engineer, something that's Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I'm very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you're talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it's really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone's going to have to rebase, everyone's going to have to communicate, or at least be aware of what happened. And so, it's not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you're doing, then you've got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that's one of the other things that Jamstack… You're introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they're getting. So, I always try to keep that in mind when I'm frustrated about how long something is taking to build, but certainly I think that's an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don't deploy a build if a test fails, but at the same time, then you've got to run all those tests.

Leslie: So, it's this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you're doing your due diligence before you actually deploy something. And we're playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you're then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn't the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they're working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we're growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I'm just aware of who's managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I've seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there's an error that got thrown, either from Netlify or from your own code, it'd be nice to be able to link directly to that log line. So, that's sort of a fun, small improvement that I've been thinking about a bit. And that's not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I'm still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it's really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn't want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn't it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it's exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it's a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we've been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that's always a big question. I mentioned Cypress before, we've been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I've been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that's been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I'm starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That's exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she's @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?