Leslie Cohn-Wein과 함께하는 스매싱 팟캐스트 에피소드 29: Netlify Dogfood The Jamstack은 어떻게 되나요?

이 에피소드에서는 Netlify에서 Jamstack을 dogfood하는 것이 어떤 것인지 묻고 있습니다. 전체 앱을 CDN에 배포할 수 있습니까? Drew McLellan은 Netlify 직원 엔지니어인 Leslie Cohn-Wein과 이야기를 나누었습니다.

메모 표시

• 레슬리의 개인 사이트
• 트위터의 레슬리
• 네틀리파이

주간 업데이트

• react-three-fiber를 사용하여 React 및 Three.js에 대해 알아보기
  작성자 Fortune Ikechi
• 전자상거래 UI 디자인을 위한 모범 사례
  저자 수잔 스카카
• Auth0으로 React 앱 인증하기
  Nefe Emadamerho-Atori가 작성했습니다.
• 전문가로부터: COVID-19 동안의 글로벌 디지털 접근성 개발
  저자 로빈 크리스토퍼슨
• Vue 3의 새로운 기능은 무엇입니까?
  저자 티미 오모예니

성적 증명서

Drew McLellan: 그녀는 수상 경력에 빛나는 프론트엔드 전문가입니다. 원래 오스틴 출신이지만 지금은 뉴욕에서 잠시 일을 하다가 텍사스 주 댈러스에 살고 있습니다. 에이전시에서 일하는 동안 그녀는 Nintendo, WorldPride 및 Jerry Seinfeld와 같은 클라이언트를 위한 사이트를 구축했습니다. 그녀는 현재 Netlify의 직원 프론트엔드 엔지니어로, 무엇보다도 고객이 서비스 및 배포를 관리하는 데 사용하는 애플리케이션을 구축하는 일을 하고 있습니다. 그래서 우리는 그녀가 뛰어난 프론트엔드 엔지니어라는 것을 알고 있지만 뉴욕시에 살 때 3년 연속으로 보조 칠리 요리 심사위원으로 일했다는 사실을 알고 계셨습니까? 그리고 그것은 사실입니다. 나의 멋진 친구들이여, Leslie Cohn-Wein을 환영하십시오. 안녕, 레슬리. 잘 지내고 있나요?

Leslie Cohn-Wein: 굉장합니다.

Drew: 저는 오늘 Netlify가 Jamstack을 기반으로 구축할 때 매력적인 표현을 사용하기 위해 자체적으로 개 사료를 먹는 방법에 대해 이야기하고 싶었습니다. 몇 달 전까지만 해도 우리는 Netlify의 같은 팀에서 함께 일했었다고 말하면서 이 상황을 조금 이해해야 합니다. 그리고 내가 그곳에 도착했을 때, 개발 과정은 사실 20년의 개발자 생활을 했음에도 불구하고 나에게 정말 낯설었습니다. 더 많은 청중과 함께 정말 흥미롭고 조금 탐구할 가치가 있다고 생각했습니다. 나는 이것이 진정으로 흥미로운 사례 연구를 만들고 Netlify를 위한 후원을 받는 큰 광고가 아니기 때문에 우리가 이것에 대해 이야기하고 있다는 점을 지적해야 할 것입니다. 모두 Vercel을 확인해야 합니다. 그러나 특히 Jamstack의 관점에서 토론을 통해 배울 수 있는 가치 있는 것들이 많이 있다고 생각합니다. Netlify는 Jamstack 접근 방식을 강력하게 지지하고 서비스가 일종의 고객에게 제공되고 Jamstack 프로젝트를 구축한다는 아이디어를 기반으로 구축되기 때문입니다. 그러나 서비스도 이러한 원칙 자체를 사용하여 구축됩니다. 그렇지 않아?

레슬리: 그렇습니다. 많은 사람들이 Jamstack 아키텍처를 정적인 사이트로 생각하지만 Netlify 프론트엔드로 Jamstack 앱을 빌드한다는 것이 무엇을 의미하는지에 대해 정말 열심히 연구하고 있습니다. Netlify에 Netlify를 배포하는 전체 Jamstack 앱인 React 앱이기 때문에... 예, 실제로 시도하고 있으며 가능한 한계를 뛰어넘고 있습니다.

Drew: Jamstack이 정적 사이트에만 적합하다는 생각이 가끔 있는 것 같습니다. 말씀하신 것처럼 이메일 주소로 양식을 보내고 싶을 때 API 측면이 필요하고 그런 간단한 작업을 수행할 수 있지만 그런 식으로 전체 웹 앱을 빌드할 수 있습니다. 그런데, 그렇게 하고 있는 거 아닙니까?

레슬리: 네, 물론입니다. app.netlify.com에 로그인할 때 보게 되는 내용에 대해 구체적으로 설명하는 우리 앱은 다음으로 구동됩니다. 내부 REST API가 있지만 내가 말했듯이 프론트엔드는 순수한 Jamstack입니다. 따라서 자체 빌드 단계가 있고 앱에서 빌드되는 앱을 보고 자체 시스템에 배포합니다.

Drew: 따라서 백엔드 프로세스가 관련되어 있고 항상 일종의 백엔드 프로세스 수준이 있을 때 데이터를 유지하거나 Netlify의 경우 배포 또는 보유한 것으로 시작하여 해당 백엔드는 프론트엔드에서 사용할 수 있는 일련의 API로 빌드되는 종류는 무엇입니까?

Leslie: 네, 이 작업을 수행하는 방법에 대한 몇 가지 다른 모델이 있습니다. 대부분의 경우 앱에서 React와 함께 클라이언트 측 가져오기를 사용합니다. 맞죠? 따라서 앱의 일종의 정적 셸을 제공한 다음 요청 시 내부 REST API에서 사용자 정보를 가져옵니다. Jamstack은 미리 구축할 수 있는 몇 가지 항목이 있기 때문에 흥미롭고 가능한 한 이를 사용하려고 합니다. 그런 다음 좀 더 동적인 데이터에 대해 이야기할 때 가장 최신 데이터를 가져오는지 확인하기 위해 해당 클라이언트 측 가져오기를 사용합니다.

Drew: 앱 작업을 시작했을 때 프론트엔드에서, 특히 외부 API 및 사물과의 상호 작용과 관련하여 얼마나 많은 것을 달성하고 있는지에 대해 놀랐다고 생각합니다. Netlify가 Git 공급자와 상호 작용할 때 GitHub로 이동하여 저장소 목록을 가져오는 것은 모두 브라우저와 GitHub 사이에서 발생한다는 것을 알고 있습니다. 그리고 아마도… 요청에 일부 비밀을 넣는 서버리스 기능을 거치거나 이와 유사한 경량 기능을 거치는 것 외에는 대부분이 Jamstack과 같은 방식으로 발생합니다. Netlify 종류의 핵심 백엔드 인프라를 거치지 않습니다. 매우 매력적입니다. 이는 실제로 약간의 API 호출을 통해 작은 작업을 수행하는 정적 사이트 그 이상입니다. 이것이야말로 진정한 핵심 기능입니다. 브라우저에서 구현되고 있는 것 아닙니까?

레슬리: 물론입니다. 프론트엔드 개발자 엔지니어가 무엇인지에 대한 개념을 정말 밀어붙이는 것 같아요. 맞죠? 그리고 이것은 프론트엔드 엔지니어로서 저를 더 잘하고 그런 종류의… API 계층에 대해 더 많이 생각하도록 밀어붙이는 것입니다. 저는 UI, 색상 및 디자인 시스템에서 더 많은 일을 하고 있습니다. 그래서 정말... 실제로 Jamstack 앱을 대규모로 작업하면서 더 나은 개발자가 될 수 있다는 것을 알게 되었습니다.

Drew: 프론트엔드 개발자가 된다는 것은 CSS의 일부이지만 CSS를 앞뒤로 모른다는 것입니다. HTML을 앞뒤로 알지는 못하지만 그것이 일부입니다. 또한 전통적으로 백엔드 엔지니어의 전유물이었던 이 영역을 벗어나고 있습니다. 이는 매우 흥미로운 일입니다. Netlify는 다음을 위해 새로운 서버 측 렌더링을 사용합니까?

Leslie: 내가 알고 있는 것은 아닙니다.

Drew: 말 그대로 모든 것이 완료되었습니다. 당신이 말했듯이 쉘을 제공하면 다른 API 끝점에 대한 요청으로 채워져 모든 것을 채우는 것입니다.

레슬리: 맞습니다.

Drew: 그리고 그것이 React 앱이라고 말씀하십니까?

레슬리: 네. 네. 반응합니다. 우리는 지금 React Redux를 사용하고 있고 지금은 PostCSS이지만 CSS 아키텍처도 실험하고 있습니다.

드류: 우리 모두가 그렇지 않습니까? 그래서 React에서 앱을 빌드한 다음 Netlify에 배포합니까?

레슬리: 네. 전체 프로세스에서 내가 가장 좋아하는 부분은 Netlify를 통해 얻을 수 있는 Deploy Previews의 마법일 것입니다. 그래서 일어나는 일은... GitHub에서 일하고 PR을 올리는 것입니다. 따라서 GitHub에서 PR을 열면 앱의 Deploy Preview 빌드가 자동으로 생성됩니다. 따라서 실제로 앱 자체의 Deploy Previews를 사용하여 모든 것이 제대로 작동하는지 확인합니다. 우리는 우리의 테스트를 실행합니다. 이것이 우리가 코드 검토 중에 수동으로 확인하는 데 사용하는 것입니다. 따라서 GitHub에서 바로 모든 지속적인 배포를 설정했습니다.

Leslie: 그리고 우리가 설정한 다른 멋진 점 중 하나는 실제로 앱이 있는 동일한 리포지토리에서 가져오는 두 개의 서로 다른 Netlify 사이트가 있다는 것입니다. 따라서 우리는 두 앱을 모두 가지고 있으며 앱에 대한 일종의 UI 구성 요소가 있는 Storybook 인스턴스를 가지고 있습니다. 따라서 앱 자체가 있고 Storybook UI 구성 요소가 있으며 기본적으로 Storybook UI를 보여주는 Netlify 사이트가 있습니다. 그리고 웹팩 번들 분석기를 실행하는 세 번째 사이트도 있습니다. 트리 맵, 모든 앱 번들의 시각화를 제공하는 시각적 UI입니다. 우리는 크기를 측정할 수 있으며 일종의 재확인을 상기시켜줍니다. 앱이 배포될 때마다 번들 크기가 이상하지 않은지 확인할 수 있습니다. 따라서 이 세 사이트는 모두 앱의 하나의 Pull Request로 생성됩니다. 따라서 우리가 확인할 수 있도록 앱 스토리북과 해당 앱 프로필의 미리보기 링크, 즉 기본적으로 배포 미리보기 링크를 받게 됩니다.

Drew: 그리고 Deploy Previews를 사용하면 본질적으로 일종의 스테이징 환경이 됩니다. 그렇지 않나요?

레슬리: 맞습니다. 우리는 실제로 기존 스테이징 환경을 실행하지 않습니다. 왜냐하면 우리는 Deploy Previews가 기본적으로 병합 버튼을 누르고 메인 앱에서 메인 브랜치의 공식 빌드를 시작할 때 라이브로 갈 것이라고 정말로 믿기 때문입니다. 따라서 Deploy Previews를 스테이징 환경으로 사용할 수 있다는 점이 마음에 듭니다. 우리는 그것이 생산과 일치할 것이라고 정말로 믿습니다. 우리는 모든 프로덕션 변수, 환경 변수, 그 모든 것이 Deploy Preview에서 빌드되는 모든 것을 사용하여 빌드하고 있습니다. 따라서 걱정할 필요가 없는 상황과 거의 같습니다. Deploy Preview가 작동하는 한 앱도 작동한다는 것을 알 수 있습니다.

Drew: 그리고 내 생각에 조직으로서 Deploy Preview가 라이브 상태와 일치하지 않는 경우 Netlify가 해결하고자 하는 서비스 문제입니다. 따라서 실제로 관점에서 보면 꽤 잘 작동합니다. 따라서 배포 미리 보기를 검토했으며 모든 것이 멋지게 보이고 PR이 병합되었습니다. 그러면 어떻게 됩니까?

Leslie: Netlify가 모든 지속적인 배포를 실행하기 때문에 기본적으로 모든 것이 연결되어 있어 기본 분기에 병합하면 앱과 함께 공식 프로덕션 배포가 자동으로 시작됩니다. 따라서 일반적으로 자신의 PR을 병합한 개발자인 경우 실제 ... 탭을 다시 확인해야 합니다. 앱의 배포 미리보기가 열려 있고 앱이 당신은 확인해야합니다 ... 당신은 일반적으로 실제 앱에서 따라하기를 원합니다. 따라서 탭을 확인해야 합니다. 그러나 예, 앱에서 일반적으로 들어가고 방금 시작한 병합에 대한 빌드 로그를 볼 수 있으므로 모두 자동입니다. 그런 다음 해당 빌드 로그가 완료되고 사이트가 활성화되면 브라우저 창을 새로 고치기만 하면 방금 배포한 모든 항목이 앱에서 업데이트되어야 합니다.

Drew: 그리고 문제가 라이브 상태가 된 후 포착했다고 가정해 보겠습니다. 그러면 어떻게 합니까?

레슬리: 아주 좋은 질문입니다. 그리고 Netlify에서 일하기 전에도 Netlify를 사용하면서 가장 좋아하는 것 중 하나는 Netlify가 일종의 구운 것, 즉 롤백이기 때문에 저에게는 약간의 마법과도 같았습니다. 따라서 기본적으로 Netlify의 모든 배포는… 우리가 이 Jamstack 아키텍처를 사용하기 때문에 모든 배포는 원자적입니다. 이것이 의미하는 바는 사이트에서 수행한 모든 종류의 배포에 대한 전체 기록이 있으며 그 중 하나로 즉시 롤백할 수 있다는 것입니다. 따라서 실수로 버그를 배포하거나 무언가가 중단된 경우 일반적으로 가장 먼저 하는 일은 실제로 지속적인 통합을 중지하는 것입니다. 그래서 우리는 들어가겠습니다. Netlify UI에서 "자동 게시 중지"라고 말하는 버튼 하나만 있으면 GitHub와의 연결이 중지됩니다. 따라서 팀원이 갑자기 PR을 병합하면 버그를 다시 도입하지 않을 것이며 그런 일은 일어나지 않을 것입니다.

Leslie: 그래서 우리는 모든 자동 배포를 중지합니다. 그런 다음 내가 해야 할 일은 배포 목록으로 돌아가서 마지막으로 작동하는 배포를 찾고 "이 항목을 게시하십시오"라고 표시된 버튼을 하나 더 누르는 것입니다. 그러면 실행됩니다. 그래서, 그것이 하는 일은 정말로 돌아가서 코드를 보고 실제로 무슨 일이 일어났는지 알아낼 수 있도록 압력을 없애는 것입니다. 때로는 메인 브랜치에서 Git 되돌리기를 수행하고 메인 브랜치를 필요한 위치로 되돌리는 것을 의미합니다. 그리고 때때로 그것은 핫픽스이거나 지점에 가서 수정하면 Git에서 되돌리는 것에 대해 걱정할 필요조차 없습니다. 그런 다음, 돌아갈 준비가 되면 앱의 Deploy Preview에서 모든 것이 제대로 작동하는지 확인하고 모든 항목을 백업하여 재설정할 수 있습니다. 따라서 자동 배포를 시작하자마자 기본적으로 다시 비즈니스에 복귀하게 됩니다.

Drew: 여기에서 문제를 발견했습니다.

레슬리: 어.

Drew: Netlify 앱에 변경 사항을 배포하기 위해 Netlify를 사용하고 있습니다. 배포한 버그로 인해 롤백이 중지되면 어떻게 됩니까? 그러면 어떻게 합니까?

레슬리: 악몽을 꾸어요. 아니요. 사실, 우리는 그것을 처리할 수 있는 몇 가지 방법이 있습니다. 따라서 앱을 중단하고 UI를 사용하여 이 프로세스를 진행할 수 없는 경우 배포 미리 보기가 실제로 프로덕션 API에 대해 실행됩니다. 따라서 이것이 의미하는 바는 앱이 작동하지 않더라도 여전히 원자적 배포가 있다는 것입니다. 따라서 GitHub의 링크, 아마도 이전 또는 최근 PR의 링크가 있고 해당 Deploy Preview URL이 있는 경우 실제로 앱의 Deploy Preview에 액세스하고 필요한 변경을 수행하고 돌아가서 이전 배포를 게시할 수 있습니다. 배포 미리보기에서. 그리고 그것은 여전히 ​​우리의 프로덕션 API에 영향을 미치므로 여전히 앱에 영향을 미치고 앱을 다시 불러올 것입니다. 그것은 일종의 폭발하는 뇌 이모티콘과 같지만 그것을 하는 한 가지 방법입니다. 일부 백엔드 시스템에서 이전 배포를 게시할 수도 있습니다. 백엔드 엔지니어가 이를 게시하도록 할 수 있습니다. 또는 항상 Git을 사용하여 되돌리고 시도하고 푸시할 수 있지만 수행 중인 작업을 볼 수 없기 때문에 약간 무섭습니다.

드류: 그 상황을 관리하려면 아주 맑은 정신이 필요하다고 생각합니다.

레슬리: 네.

Drew: 하지만 완전히 복구할 수 있는 것 같군요.

레슬리: 네. 작업 배포를 게시하고 나면 모든 부담이 사라집니다. 정말 멋진 부분입니다. 그리고 나는 이것이 에이전시에서도 작동하는 것을 발견했습니다. 롤백할 수 있다는 것은 정말 생명의 은인이었습니다... 또한 새로운 변경 사항을 게시하는 것에 대한 걱정도 덜었습니다. 무언가를 부수면 다시 되돌리는 데 1초가 소요됩니다. 이는 빠르게 움직이는 종류와 매우 잘 맞아서 모델을 꺼내는 것입니다.

드류: 확실히. 일반적으로 이러한 종류의 전체 워크플로는 정말 작은 변경을 처리할 때 가장 잘 작동한다고 생각합니다. 내 말은, 이상적으로는 지점을 만들고, 작은 변경을 구현하고, PR을 올린 다음 가능한 한 빨리 다시 병합하는 것이 좋습니다. 조정 및 버그 수정 및 작은 일에는 분명히 잘 작동하지만 해당 기능이 배포 준비를 시작하는 데 몇 주 또는 몇 달이 걸릴 수 있는 주요 기능 작업에는 제대로 작동하지 않습니다. 그런 프로세스를 어떻게 관리합니까?

레슬리: 네, 좋은 질문입니다. 그래서 우리는 최근에 기능 플래그를 조금 더 사용하기 시작했습니다. 가기 전에 우리가 어떻게 하는지에 대해 조금 더 이야기하기 전에 우리가 했던 일에 대해 이야기하겠습니다. 따라서 기능 플래그를 사용하기 전에 모두가 장기 실행 기능 분기에 대한 아이디어에 익숙하다고 생각합니다. 우리는 모두 그들을 싫어합니다. 그렇죠? 그러나 우리는 더 작은 PR에 대해 작업할 것입니다. 코드 검토 후 더 오래 실행되는 이 기능 분기에 각각을 개별적으로 병합합니다. 따라서 기본적으로 모든 새 기능이 한 곳에 있고 새 기능을 테스트할 수 있는 하나의 배포 미리 보기가 있을 수 있습니다. 때때로 이 모델은 다른 팀에 걸쳐 필요한 조정된 배포를 요구했습니다. 그래서 우리가 "좋아, 이 기능 분기, 우리는 그것을 병합하고 사용할 준비가 되었습니다"라고 말할 준비가 되었을 때 때때로 "좋아, 백엔드가 변경 사항을 이미 배포했는지 확인해야 합니다." 기능에서 수행 중인 API 작업을 시작할 준비가 되었습니다. 문서 사이트에 기능과 동시에 게시해야 하는 문서가 있는 경우, 조정하고 동시에 버튼을 눌러야 합니다.

Leslie: 이 모델은... 우리에게 효과가 있었지만 아마도 가장 매끄럽지 않았던 것이 맞습니다. Netlify의 공동 설립자이자 CEO인 Matt Biilmann은 실제로 작년 Jamstack Conf London 무대에서 이 프로세스를 사용하여 분석 기능을 출시했습니다. 그래서 그는 우리의 잠금 배포 기능을 사용하여 기본적으로 분석의 새로운 기능에 대한 배포 미리보기를 가져와 무대에서 라이브로 게시했습니다. 그래서, 그것은 꽤 멋졌다.

Leslie: 하지만, 당신이 말했듯이, 그것은... 당신이 조금 덜 자신감이 있다는 것입니다. 이 Pull Request에는 모든 것이 여전히 숨겨져 있습니다. 조금 버거워집니다. 누군가는 일반적으로 꽤 큰 최종 Pull Request를 승인해야 합니다. 조금 압도적입니다. 그래서 오늘날 우리는 주로 기능 플래그를 사용하고 있습니다. 우리는 LaunchDarkly라는 서비스를 사용합니다. 기본적으로 이러한 플래그로 새로운 기능 UI를 래핑할 수 있으므로 UI가 고객에게 표시되기를 원하는 것이 아닌 경우에도 계속 코드를 병합할 수 있습니다. 따라서 프로덕션 환경에서 기능 플래그가 꺼져 있는지 확인하고 코드를 배포하고 병합할 수 있으며 아무도… 일반 사용자라고 가정하면 새 UI가 표시되지 않습니다.

Drew: 따라서 기능 플래그는 기본적으로 "이 기능이 활성화되어 있으면 이 새 코드를 사용하고 그렇지 않으면 이 이전 코드를 사용하십시오."라는 코드의 스위치와 같습니다.

레슬리: 맞습니다.

Drew: 이 모든 포크가 제자리에 있는 지저분한 코드 기반을 갖게 된다는 뜻인가요? 어떻게 처리합니까?

Leslie: 예, 제 생각에는... 기능 플래그를 사용하는 사람이라면 누구나 언제 기능 플래그를 정리하는지에 대한 이런 종류의 전투에 익숙할 것입니다. 얼마나 오래 거기에 두십니까? 우리는 주요 기능이 출시된 지 약 2주 만에 착륙했습니다. 미리 알림이 있다는 것입니다. 운 좋게도 LaunchDarkly는 실제로 최근에 Slack에 알리는 기능을 설정했습니다. 따라서 Slack과 연결하면 "이봐, 기능 플래그는… 이제 코드에서 플래그를 정리해야 할 때입니다.”

Leslie: 그래서, 우리는 그것을 시도하고, 꽤 빨리 청소하지만, 그 사이에 깃발이 여전히 있다는 것을 아는 것이 좋습니다. 기능을 출시한 경우에도 다시 한 번 클릭으로 들어가서 해당 플래그를 다시 끌 수 있음을 의미합니다. 버그가 있는 경우 팝업되는 항목이 있는 경우입니다. 따라서 기능이 실제로 베이킹되고 사람들이 익숙해지는 동안 큰 문제가 없는지 확인하기 위해 잠시 동안 그대로 두는 것이 좋습니다. 하지만 우리는 다시 코드로 돌아가려고 시도하고 약간의 정리 작업이므로 이상적인 프로세스는 아니지만 일반적으로 플래그를 제거하는 데 그리 오랜 시간이 걸리지 않으며 몇 줄의 코드만 삭제하면 됩니다.

Drew: 따라서 기능 플래그를 구현하는 가장 간단한 방법은 "이 기능은 설정 또는 해제되어 있습니다."라고 말하는 앱의 구성 변수와 같은 것일 수 있습니다. 적합한 사람들을 위해 켜져 있고 적합한 사람들을 위해 꺼져 있습니다. 그리고 그것이 LaunchDarkly와 같은 서비스가 필요한 곳이라고 생각합니다. 왜냐하면 그것이 필요하기 때문입니다... 제 말은, 기본적으로 변수를 극단적인 수준으로 켜고 끄는 것이 필요하지 않습니까?

레슬리: 네. 네. 바로 그것입니다. 따라서 LaunchDarkly가 없어도 기본적으로 자체적으로 관리하는 구성 변수를 직접 설정할 수 있는 방법이 있습니다. 내가 LaunchDarkly에 대해 좋아하는 것 중 하나는 다양한 환경이 있다는 것입니다. 따라서 우리가 할 수 있는 일은 기본적으로 배포 미리보기에 대한 기능 플래그를 켜는 것입니다. 따라서 앱의 배포 미리 보기인 Netlify에서 내부적으로 보고 있는 사람은 누구나 새 기능에 액세스할 수 있고 테스트할 수 있지만 다시 프로덕션 환경에 적용되는 즉시 해당 플래그가 꺼집니다. 그래서, 거의 없습니다… 다시, 당신은 탭을 확인하고 당신이 속한 세그먼트의 종류를 알고 있는지 확인해야 합니다. 당신은하지 않았다, 당신은 거기에서 조금 조심해야합니다. 그러나 일반적으로 매우 잘 작동하며 LaunchDarkly를 사용하면 이러한 선택적 롤아웃도 수행할 수 있습니다. 따라서 코드 기반의 일정 비율이나 특정 사용자 세그먼트, 특정 유형의 계획을 가진 사람들 또는 특정 유형의 사용자에게 기능을 롤아웃할 수 있습니다. 따라서 누구에게 공개할지 훨씬 더 많이 제어할 수 있습니다.

드류: 네. 특히 문제를 해결할 것으로 예상되는 새로운 기능이나 기능이 있는 경우에는 정말 강력할 수 있습니다. 더 이해하기 쉽게 기능을 개선하고 있을 수도 있고, 사용자의 10%와 함께 사용해 보고 동일한 문제를 겪고 있는지 확인할 수도 있습니다.

레슬리: 맞습니다. 피드백을 받는 것도 좋은 방법입니다.

Drew: 이 방식으로 LaunchDarkly를 사용하는 것은 자체 솔루션을 구현하는 것보다 Jamstack 접근 방식의 또 다른 측면이라고 생각합니다. 그렇죠? 스스로 구현하는 방법과 개발 방법, 유지 관리 및 유지 관리 방법에 대해 걱정할 필요 없이 이 기능을 제공하는 API를 사용하는 것뿐입니다. 이 API를 사용하면 나머지는 모두 처리됩니다."

레슬리: 네. 네, 정확히.

Drew: 따라서 이 접근 방식을 사용하면 기본적으로 프로덕션에 약간의 새로운 기능을 커밋할 수 있지만 플래그 뒤에 숨겨져 있는 것입니다. 그런 다음 모든 준비가 완료되면 플래그를 뒤집기만 하면 문제가 발생하면 다시 빠르게 다시 전환할 수 있습니다.

레슬리: 네, 맞습니다. 그것은 우리의 출시를 조금 덜 흥미롭게 만듭니다. 예전에는 이 큰 버튼을 누르고 있고 이 모든 코드가 병합되고 빌드 로그를 보고 있고 지금이 기대되는 순간입니다. 이제 Zoom 통화에 뛰어들어 버튼 하나를 클릭하면 바로 통화가 됩니다.

드류: 네. 저는 마지막 기능 출시 때 Netlify에서 작업했으며 이 접근 방식을 사용했다고 생각합니다. 그리고 전체 팀이 몇 주 동안 작업했으며 릴리스를 조정하기 위해 Zoom에 전화를 걸었고 모두가 부품이 준비되었음을 확인했습니다. 그런 다음 기능 플래그를 뒤집어 모든 사용자에 대해 켰습니다. 그게 전부였습니다.

레슬리: 끝났어.

Drew: 그리고 그것은 몇 분 안에 끝났고 정말 극적이었습니다.

레슬리: 네, 좀 슬프네요.

Drew: 땀에 젖은 손바닥도 없었고 아무것도 없었습니다. 물론 정확히 당신이 원하는 것입니다. 그렇죠? 그렇게 하면 모든 사람을 위해 무언가를 켜는 것이 큰 문제가 아닌 경우 강력한 프로세스가 있음을 알 수 있습니다.

레슬리: 맞습니다. 다시 롤백해야 한다면 클릭 한 번으로 간단합니다. 그 압박감, 불안을 조금이나마 덜어줍니다.

Drew: 아마도 모든 변경 사항이 프론트엔드 변경 사항이 아닐 것입니다. 때때로 백엔드 변경이 있을 것이며 아마도 대부분의 백엔드 시스템에도 고유한 기능 플래그가 있을 것입니다. 그래서 당신은 문서도 언급했습니다. 이 모든 것을 함께 조정할 수 있는 방법이 있습니까? 모두가 동시에 깃발을 펄럭이는가? 또는 어떻게 작동합니까?

레슬리: 네. 따라서 이것은 Netlify에서 현재 여러 팀에서 적극적으로 작업하고 있는 영역이며 모든 시스템을 LaunchDarkly의 단일 플래그에 연결할 수 있는 솔루션을 위해 노력하고 있습니다. 이 솔루션은 모든 시스템에서 사용하고 있습니다. , 우리의 모든 코드 기반이 사용하고 있습니다. 따라서 이상적인 세계에서는 플래그를 뒤집고 다음과 같이 말할 수 있습니다. 이 새로운 기능에 대한 새로운 정보가 있는 문서 사이트의 이 부분도 마찬가지입니다." 그리고 그 안에 있는 하나의 플래그를 뒤집으면 모든 저장소에 영향을 줍니다. 아직 도착하지 않았습니다. 우리는 그 문제를 해결하기 위해 노력하고 있지만, 우리가 이 모든 것을 조정하고 작동할 수 있는지 확인하게 되어 매우 기쁩니다.

Drew: Netlify 서비스는 이러한 방식으로 사이트를 구축하는 데 매우 적합합니다. 귀하와 귀하의 팀이 제품을 사용하여 수행하는 작업이 실제로 제품 개발에 전혀 영향을 미칩니까?

Leslie: 확실히 그렇습니다. 모든 사람들은 항상 당신이 당신의 사용자가 아니라고 말하는데, 나는 때때로 당신이 당신의 사용자일 때를 제외하고는 대부분 사실이라고 생각합니다. 특히 프론트엔드 팀에 있는 대부분의 사람들이 이전에 Netlify를 제품으로 사용한 적이 있는 사람들이라고 생각하기 때문에 Netlify에서 재미있는 일입니다. 그리고 확실히 Netlify를 사용하여 Netlify를 배포하기 때문에 일부 사용자가 겪는 것과 동일한 문제에 직면하게 됩니다. 따라서 어떤 면에서 문제가 발생하면 나머지 회사에 문제를 제기하려고 합니다. 엔지니어링 통화에서 이를 언급하거나 CTO를 불러와 다음과 같이 말합니다. 우리와 유사한 것을 배포하는 모든 사용자를 위해 제품에 구축할 수 있는 것이 있습니까?” 그래서 독특한 위치에 있지만 제품 로드맵이 어떻게 발전하는지 보는 것은 재미있습니다.

Drew: Netlify 자체만큼 Netlify를 집중적으로 사용하는 사람은 거의 없을 것입니다.

레슬리: 네. 응. 그 정도가 맞다고 생각합니다. 저는 Netlify를 구축할 때와 배포할 때 모두 응시하기 때문에 꽤 익숙합니다.

Drew: 그리고 주말에 사이드 프로젝트를 진행하다가 Netlify로 다시 돌아옵니다.

레슬리: 네. 그것은 실제로 매우 사실입니다. 응. 네. 네 확실합니다.

Drew: 팀이 수행한 작업이 제품 방향에 어떤 영향을 미쳤는지에 대한 예가 있습니까?

레슬리: 네. 그래서 우리는 최근에 팀 개요라고 하는 앱에 대한 새로운 종류의 랜딩 대시보드를 출시했습니다. 따라서 Netlify에 로그인하면 기본적으로 사이트의 긴 목록이 되는 사이트 페이지로 이동했습니다. 그리고 우리는 사람들에게 많은 중요한 정보를 한 눈에 볼 수 있고 가장 유용할 항목에 액세스할 수 있는 임무 제어 영역을 조금 더 제공하고 싶었습니다. 그래서 그것은 우리가 구축한 새로운 기능이었습니다. 초기 반복에서 우리는 그것을 빨리 꺼내려고 노력하고 있습니다. 우리는 그 UI에 최신 빌드로 연결되는 작은 카드를 가지고 있습니다. 팀 전체의 모든 빌드가 해당 카드에 표시되어야 함을 보여줍니다.

Leslie: 그리고 처음에 우리는 실제로 그것들을 빌드에 연결하지 않았습니다... 디스플레이 로그 자체. 그래서 그냥 확인할 수 있는 목록이었습니다. 빌드 페이지를 클릭하여 유사한 보기를 얻을 수 있습니다. 하지만 실제로 주말에 개인 사이트에서 작업을 하고 있었는데 이 팀 개요가 켜져 있었고 Netlify에 로그인하고 내 프로젝트에서 진행 중인 이 빌드를 확인하고 싶었기 때문에 짜증이 났습니다. 클릭하고 바로 이동할 수는 없었습니다. 빌드 페이지를 클릭한 다음 다시 클릭해야 했습니다. 그래서 다음 날 직장에 가서 그 변경 사항을 추가하고 저를 귀찮게 했기 때문에 해당 빌드를 연결했습니다. 그래서 그것은 제품을 사용하여 개선할 수 있는 아주 작은 기회가 있음을 깨닫는 일종의 예였습니다. 그리고 우리는 그것을 가져갔습니다.

Leslie: 하지만 다른 예도 있습니다. 아마 조금 더 임팩트가 있지 않을까. 하나는 이 양식 감지 기능을 추가했다는 것입니다. 따라서 약간의 배경 지식이 익숙하지 않다면 Netlify 양식은 프론트엔드 양식을 구축할 수 있는 Netlify의 기능입니다. Netlify는 제출물 관리의 모든 백엔드 작업을 수행합니다. 프론트엔드에 구축한 양식에 대한 데이터베이스와 같습니다. 즉, 양식 제출을 관리하기 위해 서버 측 코드나 많은 추가 JavaScript를 작성할 필요가 없습니다. 실제로 Netlify에 배포한 모든 사이트는 빌드가 진행되는 동안 Netlify가 주의하고 관리해야 하는 Netlify 양식이 있는지 기본적으로 감지하기 위해 배포 시 사이트의 HTML을 구문 분석합니다. 그리고 빌드 봇이 찾는 이 양식 감지는 기본적으로 활성화되어 있습니다.

Leslie: 하지만 이것이 의미하는 바는 상상할 수 있듯이 봇이 이 추가 단계를 찾아 이동해야 하기 때문에 빌드 시간이 약간 소모된다는 것입니다. 따라서 Netlify 앱 자체는 실제로 사용하지 않고 있으며 현재 앱에 Netlify 양식이 없습니다. 따라서 이것은 기본적으로 빌드 시간에 약간을 추가하는 단계이지만 반드시 일어날 필요는 없습니다. 따라서 Netlify는 실제로 모든 사용자가 해당 양식 감지를 비활성화할 수 있는 새로운 기능을 구축했습니다. 이것이 의미하는 바는 사이트 설정에서 해당 설정을 끌 수 있다는 것입니다. 빌드 봇은 찾을 필요가 없음을 깨닫고 빌드에서 추가 처리 시간을 조금 절약할 수 있습니다.

Drew: 생산성 면에서 대단한 것 같아요. 작업이 조금 더 빨리 완료되기 때문입니다.

레슬리: 맞습니다.

Drew: 그러나 또한 계량 서비스로서 귀하가 가지고 있는 수당에서 더 많은 것을 얻을 수 있습니다.

레슬리: 네. 정확히. 그래서 이것은 우리가 일부 사용자와 고객에게서 들은 것이기도 하고 우리도 알아차린 것이었습니다. “글쎄, 우리 제품에는 이 추가 단계가 필요하지 않습니다. 그렇다면 모든 사용자의 삶을 조금 더 쉽게 만들고 모든 사용자가 이 기능을 사용하지 않는 경우 조금 더 빠르게 빌드할 수 있도록 모든 사용자에게 제공할 수 있는 방법이 있습니까?”

Drew: 위험이 있습니까... 제 말은, 당신은 당신이 당신의 사용자가 아니라고 말하지만, Netlify를 사용하면 종종 당신이 당신의 사용자입니다. 당신이 제품을 사용하는 강도로 인해, 단지 그것을 아주 가볍게만 사용하는 부류의 사용자를 간과할 수 있고 모든 것이 너무 복잡하고 너무 고급화될 수 있고, 그것을 얻기가 매우 어려워질 위험이 있습니까? 로 시작?

Leslie: 좋은 질문이네요. 우리는 또한 Netlify에서 사용자 연구 기능과 데이터 과학 기능을 구축했으며 전반적으로 앱을 사용하고 배포한 제 일화보다 훨씬 더 신뢰합니다. 하지만 그런 모든 데이터가 함께 모여서 누가 Netlify를 사용하고 있는지, 어떤 유형의 사용자와 대화하고 있는지 더 잘 이해할 수 있도록 한다고 생각합니다. 다양한 필요를 가진 사람들이 있습니다. 블로그와 개인 사이트를 관리하는 스타터 팀이 있으며 Netlify 자체와 크게 다르지 않은 대규모 마케팅 캠페인과 대규모 웹 앱을 출시하는 거대한 기업도 있습니다. 따라서 사용자 기반이 증가하는 것을 보고 이러한 모든 사용 사례에 대해 생각하고 이러한 모든 사용자를 수용할 수 있는 방법을 알아내는 것은 흥미진진합니다. 그리고 확실히 우리의 내부 경험뿐만 아니라 해당 사용자가 누구인지 이해하기 위해 더 많은 연구 기능을 사용합니다.

Drew: Leslie, Netlify가 제공하는 스크린샷 서비스에 대해 말씀해 주시겠습니까? 그것이 정말 흥미로웠기 때문입니다.

레슬리: 네. 우리가 가지고 있는 UI에는… Netlify에 사이트를 배포할 때 UI에는 일반적으로 느꼈던 사이트의 홈페이지가 어떻게 생겼는지 보여주는 작은 스크린샷이 있습니다. 얼마 전에 내가 Chris Coyier의 Serverless에 대한 에피소드를 듣고 그가 CodePen에서도 스크린샷을 수행하는 방법에 대해 이야기했기 때문에 우리가 이 문제를 제기한 것이 정말 웃겼습니다. 실제로 Netlify가 수행하는 방식과 크게 다르지 않습니다. 그러나 기본적으로 우리는 사용자 사이트의 스크린샷을 캡처하기 위해 Puppeteer를 실행하며, 모두 실행되는 방식은 Netlify 기능으로 설정하는 것입니다. 그래서 이것은 다시 우리 자신의 제품을 dogfood하는 예입니다. 따라서 본질적으로 우리는 자체 앱 내부의 Netlify 기능인 이 끝점을 사용하여 스크린샷의 해당 이미지 URL을 반환하고 앱에서 이를 제공할 수 있습니다.

Drew: Netlify 기능은 Netlify가 서버리스 기능을 구현한 것 아닌가요? 기본적으로 JavaScript 파일을 소스의 일부로 지정된 폴더에 드롭하면 클라우드 기능으로 실행할 수 있게 됩니다.

레슬리: 네, 맞습니다.

Drew: 아주 똑똑하지, 그렇지?

레슬리: 네. 훌륭합니다. 이것은 프론트엔드 엔지니어로서 이 JavaScript 또는 Serverless 엔지니어에 대해 더 많은 것을 요구하는 영역 중 하나입니다. 이러한 서버리스 기능 중 하나입니다. 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. 응.

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?