대규모 조직을위한 대규모 프런트 엔드 아키텍처

(Daniel Ostapenko) ( 2020 년 10 월 14 일)

안녕하세요! 대규모 조직에서 프런트 엔드 아키텍처를 관리하는 방법에 대해 논의하고 싶습니다. 이 주제에 대한 기사가 많지 않고 잘 설명되어 있지 않다는 느낌이 듭니다.

이 기사에서 대규모 조직이란 프런트 엔드 엔지니어 수가 많아지기 시작하는 회사를 의미합니다. 15 개가 넘고 회사에는 최소한 여러 개의 프론트 엔드 프로젝트가 있습니다.

대기업에서 흔히 볼 수있는 관리 문제 나 비즈니스 도메인 문제에 대해 논의하고 싶지 않지만 집중하겠습니다. 대신 프런트 엔드 아키텍처에서만 가능합니다.

요즘에는 프런트 엔드 아키텍처가 너무 많은 영역에 관련되어 있으므로 먼저 다음 섹션으로 나눌 것을 제안합니다.

프런트 엔드 아키텍처 체계

1. 비주얼 코드

가장 쉬운 주제부터 시작하겠습니다. 제 생각에는 애플리케이션의 비주얼 코드라고 생각합니다.

원하는 동일한 회사에서 여러 프런트 엔드 애플리케이션을 개발하기 때문에 가장 가능성이 높습니다. 필요 :

  • 브랜드 인지도
  • 동일한 UI / UX

이를 달성하려면 디자인 시스템이 필요합니다. 디자인 팀은 디자인 시스템을 마련하고 향후 모든 제품 디자인에서 이러한 디자인 지침을 따라야합니다. 이 작업도 이미 매우 복잡한 작업이며 설계 팀, 엔지니어 및 제품간에 많은 논의와 조정이 필요합니다.

프런트 엔드 관점에서 구현하고 수행 할 도구를 제공해야합니다. 엔지니어간에이 설계 시스템을 공유합니다. 이에 대한 좋은 해결책은 스토리 북 또는 유사한 도구로 시각적으로 표시되는 npm 패키지를 만드는 것입니다. 제 생각에는이 패키지를 사용하는 방법에 대한 문서가 포함 된 전용 웹 리소스 (URL 포함)를 갖는 것이 매우 중요합니다.이 웹 리소스는 프론트 엔드 엔지니어와 디자이너가 사용할 것이며 그들 간의 대화.

시각적 코드

요약 :

이 시점에서 우리는 디자인 시스템을 가지고 있습니다. 패키지와 대화 형 문서로 표현합니다. 우리는 모든 프런트 엔드 애플리케이션에서이 패키지를 공유하고 채택합니다.

2. 코드 구조

매일 엔지니어링에 대해 조금. 필요한 경우 새로운 기능을 구현하고 버그를 수정하며 코드를 리팩토링합니다. 우리는 코드베이스를 멋지고 쉽게 이해할 수 있도록 만들려고 노력합니다. 그러나 회사에 1 개가 아닌 2 개가 아닌 수십 개의 작거나 큰 프로젝트가 시작되면 어떻게 될까요? 일반적으로 사람들은 일부 프로젝트를 중심으로 그룹화되어이 프로젝트 그룹에서만 작업을 시작합니다. 인간의 본성과 제한된 시간으로 인해 일반적으로 한 번에 2 ~ 3 ~ 5 개 이상의 프로젝트를 처리 할 수 ​​없습니다. 그래서 자연스럽게 영향력의 그룹. Btw, 내 비유를위한 멋진 사진을 제공 한 NASA에게 감사드립니다 😃

영향 그룹

하지만 사람들이 교차하는 경우가 점점 더 많아지기 시작합니다. -팀 협업, 서로의 코드 및 솔루션 확인, 다른 애플리케이션에서도 일부 버그 수정 또는 일부 외부 앱 내부에 필요한 사항 추가 (영향력 그룹을 위해 외부). 나쁜 소식은이 프로세스가 거의 통제되지 않은 대기업에서 일어나고 있다는 것입니다. 좋은 소식입니다. 개선을 위해 도움을 드릴 수 있습니다.

어떻게? 옳은. 동일한 코드 구조 , 코딩 및 구조화 지침 제공 회사의 프로젝트

코드 구조가 의미하는 바를 더 자세히 살펴 보겠습니다.

  • 프로젝트의 폴더 구조
    엔지니어가 새 프로젝트에 처음으로 뛰어들 때 — 해당 프로젝트와 동일한 폴더 구조를가집니다. 모든 것을 알고있는 프로젝트는 탐색 및 검색에 많은 도움이됩니다.
  • 구성 또는 지원 파일
    package.json, .gitignore, .editorconfig, 등. 모든 프로젝트에서 항상 같은 위치에 있어야하며 필요한 경우 테스트 구성 파일 또는 CI 파일에 동일하게 연결됩니다.
  • 파일 형식의 고정 위치
    동일한 파일 형식의 위치가 다음과 같은 경우 항상 동일한 구조로 작동합니다. 예를 들어 구성 요소 폴더에 항상 style.css 파일이있는 경우 :
/Component
--/Component.tsx
--/style.css
--/index.ts
  • 구성 요소 내부 구조
    파일 내부 구조는 동일해야합니다 : 가져 오기, 내보내기, 공용 기능의 위치 , 유형 등입니다. 각 파일 유형에서 예상되는 내용을 알아야합니다.
  • 이름 지정 규칙
    여기에는 폴더, 파일, 변수, 함수, 클래스, 유형 등의 이름이 포함됩니다.
  • 코딩 규칙
    일반적으로 코딩 규칙은 매우 광범위한 섹션이라고 말하고 싶지만 여기서는 ; 또는 not ; 😁 및 유사

실제로 동일한 코드 구조와 프로젝트 도구 세트가 매우 긴밀하게 결합되어 있습니다. 서로 공존하도록 도와주세요. 도구 세트 란 CLI 도구 (프로젝트 부트 스트랩, Linting, 테스트 등), IDE 확장 등을 의미합니다. 다음 섹션에서 도구 세트 주제에 대해 설명합니다.

코드 구조

요약 :

이 섹션을 적용하고 채택한 후에는 조직 전체의 모든 프로젝트에 동일한 폴더 구조, 명명 지침, 파일 구조 등이 있어야합니다. 모든 개발자 이상적으로는 다른 프로젝트로 뛰어들 수 있고 거기서 완전히 잃어 버리지 않습니다. 이 “완전히 잃어버린”것은 또한 프로젝트 내부에서 사용되는 기술 스택과 매우 연결되어 있으므로 이에 대해 이야기 해 보겠습니다.

3. 기술 스택

이전과 유사합니다. 섹션에서 조직의 프로젝트 전체에 통합 기술 스택 을 갖기를 원합니다. 그 이유는 매우 유사합니다. 우리는 엔지니어가 회사 전체의 모든 프로젝트에 익숙해지기를 바랍니다.

프론트 엔드 프로젝트에서 기술 스택의 구성 요소는 다음과 같습니다. 해당 프로젝트가 빌드 된 프레임 워크, 기본 언어, 스타일 프로세서, 데이터 레이어 (예 : Apollo), 상태 관리, 테스트, 코드 린팅, 빌드 시스템 등입니다.

물론 모든 규칙에는 예외가 있습니다. 그리고이 주제에서도 일부 기술은 글로벌 기업 전체의 기술 스택에 속하지 않더라도 특정 프로젝트에 매우 적합 할 수 있습니다. 그러나 여전히이 아이디어가 com에서 멀어 질 때마다 pany 기술 스택 그런 것들을 지원하는 데 드는 비용이 매우 높기 때문에 이점이 극적이어야하기 때문에 두 번 생각해야합니다.

여기에서 대부분의 프로젝트에 맞는 일반적인 기술 스택을 언급하겠습니다 ( 물론 실제 기술 스택의 일부만 다루지 만 누군가에게는 좋은 출발점이 될 수 있습니다 🤷) :

스택

회사에서 기술 스택을 정의하고 이에 동의 한 후 성공의 다른 매우 중요한 기둥도 있습니다. .

먼저 — 기술 스택을 문서에 기록합니다. 문서, 엔지니어간에 잘 공유되어야합니다. , 그래서 그들은 항상 증명으로 서로에 대한 링크를 제공 할 수 있습니다.

두 번째 — 다시 기록하고 문서 정의 된 기술 스택을 사용하여 새 프로젝트를 시작하고 부트 스트랩하는 방법 .

기술 스택

요약 :

위에서 언급 한 모든 사항을 구현하고 채택한 후에는 조직의 모든 프로젝트가 동일한 기술 스택을 공유하도록합니다. 이상적으로는 차이가 없습니다. 이상적으로는 차이가 거의 없습니다. 이전 섹션도 추가하면 코드, 폴더, 파일 구조도 거의 동일해야합니다. 프로젝트에서 동일합니다.따라서 모든 프로젝트를 탐색하는 것은 매우 쉬운 작업이어야합니다. 좋아요 😊

4. 도구

이 주제는 매우 중요합니다. 현재 거의 모든 곳에서 린팅, 앱 빌드, CI, 구성 요소 생성기 등의 추가 도구를 사용하고 있습니다. 그렇기 때문에 프로젝트에 적합한 도구를 선택할 수 있는지 확인하는 것이 중요합니다. 좋은 도구 vs 나쁜 도구 (또는 도구 없음), 자동화와 수동 테스트 간의 비교와 동일합니다 .

이전 섹션에서 기술 스택 및 코드 구조에 대해 이야기하고 작성해야한다고 언급했습니다. 사람들이 팔로우하도록 만드는 많은 문서. 그러나 올바른 도구 세트를 사용하면 회사의 가이드 라인에 따라 자동화 할 수 있습니다 .

예를 들어 지정된 코딩 스타일이있는 경우 사람들에게 기본적으로 해당 규칙을 따르는 linting 도구 세트를 제공 할 수 있습니다. 정의 된 기술 스택이있는 경우 좋은 CLI 도구는 기술 스택의 특정 기술로 새 프로젝트를 부트 스트랩 할 수있는 기회를 제공합니다.

의 어느 부분에 대해 논의 해 보겠습니다. 다음 도구로 프런트 엔드 아키텍처를 다룰 수 있습니다.

  • 코드 스타일 및 구조
    이전에 논의했듯이 도구로 쉽게 자동화 할 수 있습니다.
  • 프로젝트 부트 스트래핑
    You don ” 새로운 프로젝트 구조를 마련하고 필요한 모든 패키지를 수동으로 설치해야합니다.
  • 구성 요소 생성
    대부분 애플리케이션의 일부 구성 요소에는 단일 파일도 포함되어 있지 않으므로 파일 생성, 연결 / 가져 오기에 시간이 걸릴 수 있으므로 자동화 할 수 있습니다.
  • 시작 및 빌드
    물론 가장 확실한 자동 mate — 애플리케이션을 빌드하거나 시작하는 방법.
  • 테스트
    테스트 용 앱이며 실제로 모든 유형의 테스트를 실행합니다 (단위, 통합 등).
  • 종속성 관리
    아시다시피 현재 코드의 약 80 \%가 종속성입니다. 따라서 업데이트를 유지해야하며 대규모 회사에서이를 관리하는 것은 쉬운 일이 아닙니다.
  • 프로젝트 간 종속성
    우리 프로젝트는 격리 된 상태에서 작동하지 않고 다른 프로젝트에 의존하거나 다른 프로젝트에 대한 종속성 일 가능성이 높으므로 프로젝트를 연결하는 과정을 더 쉽게 해주는 도구가 필요할 수 있습니다. 여러 프로젝트의 조합으로 개발 (예 : 비트 ) 등
  • CI
    CI는 일상적인 도구 세트의 필수 부분이며이를 자동화하고 통합하면 조직에 매우 유익한 작업이 될 수 있습니다.

새로운 자체 도구 세트를 개발하고 싶지 않다면 가장 흥미로운 후보 중 하나로 NX 도구 세트 를 추천 할 수 있습니다. 또한 , Babel의 제작자가 유사한 솔루션을 수행하는 것 같습니다. 확인하실 수 있습니다. — 로마 . 이러한 도구는 모든 것을 다루지는 않지만 우리가 논의한 내용의 큰 부분을 차지하므로 좋은 출발점이 될 수 있습니다.

도구

요약 :

모든 섹션을 완료하고 채택한 후 아키텍처가 얼마나 훌륭해질 수 있는지 상상해보세요. 🧙

모든 프로젝트는 동일하며 통합 도구 세트에 의해 유지 및 관리됩니다. 각 프로젝트는 동일한 방식으로 시작하고 빌드 할 수 있습니다. 새로운 구성 요소는 동일한 위치에서 동일한 이름 지정 지침으로 생성됩니다.

하지만 “달콤”하거나 단점이 있습니까? 모든 솔루션과 마찬가지로 단점이 있습니다. 그중 하나입니다. 새 엔지니어를 회사에 온 보딩하는 데 시간이 필요합니다. 그러나 모든 것이 매우 자연스러운 방식으로 수행되고 (사람들이 이미 다른 기존 도구에 익숙해지면서) 문서화되어 있다면 개발 속도의 이점과 비교할 때 이는 큰 문제가되지 않습니다. 엔지니어가 함께 작업 할 수있는 기회입니다. 모든 코드베이스를 쉽게 등.

5. 프로덕션

프론트 엔드 아키텍처의이 부분에 대해서는 일반적으로 엔지니어가 최소한의 작업 만 처리합니다.대부분의 경우 코딩 자체와 관련이없고 그다지 흥미롭지 않을 수도 있지만 중요하지 않은 것은 아니기 때문일 수 있습니다. ☝️

프로덕션에서 일반적으로 다음 작업을 처리해야합니다.

  • Analytics
    모든 종류의 다양한 추적 이벤트 등. Google 웹 로그 분석 , 세그먼트 , HotJar 등.
  • 상태 모니터링
    여기에는 상태 확인과 같은 항목이 포함됩니다. 프로덕션, 오류보고 (예 : Sentry ) 등에서도 테스트가 실행됩니다.
  • 성능
    이전 항목과 유사하지만 성능에 더 중점을 둡니다. 여기에는 응답 시간 측정, 첫 번째 의미있는 페인트 등이 포함됩니다 (아마 도구 # 1 — 등대 )
  • A / B 테스트
    모든 종류의 A / B 테스트 솔루션 또는 기능 플래그.
  • 캐싱
    Varnish , Cloudflare .

모두 회사의 프런트 엔드 애플리케이션에서 통합 될 수 있으므로 엔지니어의 수명이 단축됩니다. . 예를 들어 사전 정의 된 초기 구성으로 패키지를 추가하고 해당 패키지를 부트 스트랩 프로젝트에 추가합니다.

제작의 또 다른 부분은 다음과 같은 코드 준비입니다.

  • 축소
    단순 코드 축소 😄
  • 소스 매핑
    소스 맵은 Sentry와 같은 다른 도구에도 필요할 수 있습니다.
  • 자산 준비
    해상도가 다른 화면, 이미지 자르기 등을위한 준비

추가 할 좋은 후보입니다. 툴링 섹션에서 언급 한 프론트 엔드 애플리케이션 관리를위한 도구 세트입니다.

제작

요약 :

이상적으로는 모든 것이 기본적으로 부트 스트랩 단계에서 각 프런트 엔드 프로젝트에 추가됩니다. 엔지니어는 도구의 올바른 위치에 올바른 API 키를 추가하는 데만주의를 기울입니다.

6. 개발

CLI 도구

부분적으로는 프론트 엔드 CLI 도구를 다루었을 때 이미 도구 섹션에서 개발 경험에 대해 논의했습니다. 통합 도구는 엔지니어의 일상적인 부분에서 큰 부분을 차지하지만 전부는 아닙니다.

API

로컬로 작업 할 수있는 편안한 API는 개발자를 개선하기 위해 할 수있는 두 번째 멋진 작업입니다. 경험과 개발 속도. 일반적으로 프론트 엔드 엔지니어를 위해 로컬로 API를 제공하는 것은 간단한 프로세스가 아닙니다. 여기에는 익숙하지 않은 도구 나 프레임 워크를 설치하는 것이 포함될 수 있습니다. 설정이 고정 된 경우에도 엄청난 양의 컴퓨팅이 필요할 수 있습니다. 개발자 컴퓨터의 리소스 (그렇지 않은 경우-설정으로 간주 할 수 있음).이 경우 솔루션이 될 수있는 것-외부 제공 API. 이것은 모든 엔지니어를위한 단일 서버 또는 부트 스트랩을위한 일부 메커니즘 일 수 있습니다. 개발을위한 전용 서버를 쉽게 사용할 수 있습니다.

CI

CI는 세 번째로 큰 부분입니다. 귀사가 이미 프런트 엔드 용 CI 도구를 선택하고이 단일 도구를 사용하고 있다고 가정 할 수 있습니다. (예 : 서클 CI ,

콘 코스 CI 또는 기타). 그렇지 않다면 통합해야합니다.

특정 프로젝트의 CI 구성은 프로젝트를 수행하는 팀의 업무에 포함되어야합니다. 이를 통해 CI에 관심이있는 사람들이 CI를 매일 사용하고 수정, 구성 및 개선 할 수있는 능력과 기술을 갖고 있기 때문에 CI가 안정적 일 수 있습니다.

그러나, 모든 작업이 팀에서 수행되어야하는 것은 아닙니다. 프런트 엔드 응용 프로그램에는 잠재적으로 필요할 수있는 매우 특정한 작업이 있습니다. 특히 폴더 / 코드 구조, 기술 스택 등을 통합 할 수 있다면 회사에서 어느 정도 시간이 지나면 CI 도구의 단계에서 이러한 패턴을 감지 할 수있게 될 때가 될 수 있습니다. 일종의 “빌딩 블록”을 제공하고 엔지니어에게 이러한 통합 “빌딩 블록”에서 CI 파이프 라인을 구성 할 수있는 기회를 제공합니다.

데모 환경

마지막으로 마지막 — 검증 구현 된 기능.엔지니어는 모든 작업을 완료하고 구현 한 후 거의 항상 모양과 작동 방식을 확인하고이를 다른 엔지니어, 디자이너 또는 기타 이해 관계자와 공유해야합니다. 이러한 요구를 위해 제공된 URL을 사용하여 특정 PR에 대해 애플리케이션의 임시 배포 버전에서 매우 잘 작동합니다.

앱 임시 배포 됨
앱 임시 배포

이 솔루션은 서로 다른 팀과 사람 간의 커뮤니케이션 속도를 크게 높여줍니다. 필수품. 그러나 일시적으로 배포 된이 버전은 일부 표면 오류나 버그를 확인하는 훌륭한 도구가 될 수 있기 때문에 가능한 한 프로덕션에 가까워 야합니다.

이는 프로젝트에 쉽게 추가 할 수 있으며 프런트 엔드의 경우 자동화 할 수 있습니다. 애플리케이션 빌드 및 배포 프로세스 파이프 라인이 통합됩니다. 또한 Kubernetes Helm 과 같은 유사 도구는 구현에 많은 도움이 될 수 있습니다.

개발

요약 :

구성 요소가있는 단일 CI 도구로 편안하고 효율적인 개발 흐름 통합 된 CLI 프런트 엔드 도구 및 데모 환경이 포함 된 CI 파이프 라인. 이 모든 것이 우리의 개발 프로세스를 최대한 원활하게 만들어야합니다. 여기에 회사의 엔지니어 수를 곱하면 얼마나 유익한 지 이해할 수 있습니다.

7. 모듈성

이 주제는 매우 크고 별도의 기사가 필요할 수 있지만 간단히 살펴 보겠습니다.

대규모 조직에서는 거대한 코드베이스가 드물지 않습니다. 맡은 일. 느린 CI 파이프 라인, 공동 작업 문제, 느린 테스트 등과 같은 모든 알려진 문제가 함께 제공됩니다. 따라서 프런트 엔드 아키텍처의 큰 부분은 독립적 인 프런트 엔드 애플리케이션 / 모듈을 얼마나 세분화할지에 대한 결정입니다.

현재 3 가지 주요 모델이 있습니다.

  • Monolith
    단일 프로젝트와 모든 코드가있는 하나의 큰 저장소, 모든 팀이이 저장소에서 동시에 작업하고 있습니다.
  • Monorepo
    많은 프로젝트이지만 여전히 하나의 큰 저장소 ( wiki의 monoorepo ). 모든 팀은 여전히 ​​동일한 저장소에서 작업하지만 다른 프로젝트로 작업합니다. 특정 프로젝트에 대해서만 파이프 라인을 실행하고 프로젝트에 더 작은 테스트 스위트가있는 등 모 놀리 식 접근 방식으로 일부 문제를 해결할 수있는 기회가 이미 있습니다. Lerna 는이 접근 방식을 선택하면 삶을 훨씬 더 쉽게 만들 수 있습니다.
  • 프로젝트 별 저장소
    각 프로젝트에는 자체 저장소와 CI 파이프 라인, 배포 등과 같은 모든 지원 항목이 있습니다.

모든 모델에서 프로젝트는 독립적 인 프런트 엔드 애플리케이션, 페이지, 독립적 인 프런트 엔드 모듈 등입니다. 이는 프런트 엔드 애플리케이션을 분할하기로 결정하려는 세분화 정도에 따라 다릅니다. 대부분의 경우이 분할은 원하는 조직 구조 및 인력 관리와 동기화되어야합니다.

애플리케이션 분할 방법을 결정한 후 두 번째로 큰 주제는 이러한 부분을 연결하는 방법입니다 (결정한 경우 애플리케이션 분할).

다음 접근 방식은 다음과 같습니다.

  • 빌드 타임 구성
    프로젝트는 npm 패키지 일 수 있으며 빌드 중에 설치 및 구성 될 수 있습니다.
  • 서버- 사이드 컴포지션
    이 접근 방식에는 일반적으로 서버 사이드 렌더링 및 서버에서 발생하는 컴포지션이 포함됩니다. Hypernova 와 같은 도구는이를 더 잘 정리하는 데 도움이 될 수 있습니다.
  • 클라이언트 측 구성
    브라우저 내의 프로젝트 구성. Martin Fowler의 블로그에는 여기 와 같은 몇 가지 접근 방식에 대한 꽤 좋은 설명이 있습니다. 또한 모듈 연합 , Webpack 5 에 도입 된 새로운 접근 방식입니다.
  • 경로 구성
    매우 간단합니다. 각 프로젝트에 자체 URL이 있으며 “Nginx 수준”에서 사용자를 리디렉션 할 위치를 결정합니다.(죄송합니다. 😄 그러나 이것이 이해하기 가장 쉬울 것이라고 생각했습니다.)

전에 말했듯이이 주제를 이렇게 작은 형식으로 다루는 것은 매우 어렵습니다. 하지만 적어도 자신에게 흥미로운 아이디어를 발견하고 직접 주제를 파헤칠 수 있기를 바랍니다. 🙏🏻 .

모듈성

요약 :

우리는 리포지토리를 구성하고 프로젝트를 작은 조각으로 분할하여 팀을 행복하고 생산적으로 만드는 방법을 찾았습니다. 팀을 서로 더 독립적으로 만듭니다.

천국에 오신 것을 환영합니다 😁

8. 테스트

프런트 엔드 애플리케이션 테스트에 사용할 수있는 리소스가 너무 많으므로 자세한 내용은 다루지 않겠습니다. 쉬움 큰 조직의 문제와이를 해결하는 방법에 더 중점을 둡니다.

첫 번째 문제는 각 엔지니어가 테스트 기술을 다르게 이해하고 어떤 기술을 어떤 상황에 적용할지, 어떻게 작성해야하는지 이해합니다. ” 따라서 회사에서 사용되는 테스트 수준의 모든 뉘앙스와 가이드 라인과 각 테스트 수준에 대한 가이드 라인을 매우 정확하게 문서화하는 것이 좋습니다.

원하는 가능한 테스트 수준 테스트 전략에 포함 :

  • 단위 테스트
  • 통합 테스트
  • E2E 테스트
  • … 및 기타

또한 두 번째 단계로 회사의 다양한 프런트 엔드 애플리케이션에서 이들을 통합해야합니다. 그래야 사람들이 다른 프로젝트로 이동할 때 테스트 할 방법과 대상에 대해 질문 할 필요가 없습니다.

테스트 수준과 접근 방식을 통합 한 경우 두 번째 문제인 테스트 인프라 설정을 자동으로 해결하는 데 도움이 될 수 있습니다. 각 프로젝트는 자체적으로 로컬 및 CI 일부 테스트 인프라를 설정하고 구성해야합니다. 예를 들어, 우리는 Cypress를 사용하기로 결정했으며 도커 이미지 내에서 실행되어야합니다. 로컬 및 CI에 설정하는 데 약간의 시간이 필요합니다. 우리가 가지고있는 프로젝트 수를 곱하면 “엄청난 시간입니다. 따라서 솔루션은 다시 통합하고 프로젝트를위한 도구를 제공하는 것입니다. 쉽게 들리지만 구현하는 데 엄청난 시간이 걸립니다.”

비 개발 시간 테스트

또한 기능이 이미 구현 및 배포 된 후 애플리케이션을 테스트하는 또 다른 방법을 다루고 싶었습니다. 물론 모니터링도 그 일부입니다 😁.

이전 섹션에서 프런트 엔드 애플리케이션에 대한 오류 및 성능 모니터링, 가동 시간 모니터링, 다른 위치의 응답에 대해 이미 언급했습니다.

Lighthouse 테스트는 웹 사이트에서 실행됩니다 (CI 파이프 라인에 포함될 수 있음). 더 쉬운 성능 병목 현상, 접근성 문제를 찾고 웹 페이지 품질을 전반적으로 개선하기 위해

그리고 마지막 — 가장 중요한 비즈니스 흐름에 대한 프로덕션 테스트입니다. 제품에서 직접 실행하면 가장 잘 작동 할 것입니다. 운영 환경에 매우 가깝거나 심지어 미러링하는 스테이징 / 테스트 환경에서 이러한 테스트를 실행할 수있을 때 수정이 가능합니다. 이 주제에 관한 아주 좋은 기사가 있습니다 — (여기).

테스트

요약 :

각 프런트 엔드 애플리케이션에 대해 정의 된 필수 테스트 수준이 포함 된 명확한 테스트 지침 모든 애플리케이션에 대해 단일 CI 파이프 라인이 있고 로컬에서 테스트를 실행하는 데 도움이되는 단일 CLI 도구가 있습니다.

최종 단어

여러분이 여기서 흥미로운 것을 발견 하셨기를 바랍니다. 조. 죄송합니다. 대부분의 주제에서 방금 문제의 표면을 긁어 모았습니다. 그리고 이에 대해 더 많은 논의를하게되어 기쁩니다. 댓글에 질문을 남기거나 트위터 ( @denieler )에서 직접 저를 핑해주세요.