내가 레퍼런스가 되자 내가 레퍼런스가 되자

현재 회사에서 운영중인 여러 서비스를 과거에 monorepo로 구성하며 겪은 과정과 내용을 정리하게 되었습니다. 서비스 운영시 repository 관리에 참고하면 좋을것 같습니다. Monorepo vs Multirepo개발 시 여러 모듈 또는 서비스를 하나의 repository에서 관리할 것인지 여러 repository에서 관리할 것인지에 따라 monorepo와 multirepo로 나누어집니다. MonorepoMonorepo 방식은 하나의 repository에서 두 개 이상의 모듈 또는 서비스를 개발 및 관리하는 방식입니다. 각각의 모듈과 서비스를 구성하는 package는 서로 의존성을 가지며 구성됩니다. 따라서 package들끼리 의존성을 가지지 않으면 monorepo라고 하긴 어렵습니다. Monore..

monorepo로 구성되어 있던 특정 package를 분리하기 위해 repositroy의 형상을 다른 repositroy로 이관하는 작업을 하게 되었습니다. 기존 repositroy의 commit 이력과 브랜치들도 다 같이 옮겨가는 니즈가 있어 해당 작업 내용을 남기게 되었습니다. Git clone mirror option기존 repositroy의 commit 이력과 브랜치들도 복사하기 위해 git clone mirror option을 사용합니다. Git clone mirror vs baregit clone에는 mirror와 bare option이 있습니다. mirror option은 기본적으로 bare option을 포함하고 있으며 bare option 과는 달리 기존 repositroy의 local ..

서비스를 운영하며 배포 시 Release와 Tag를 직접 만들었습니다. 매번 Release와 Tag를 수동으로 생성하다 보니 불편함을 느끼게 되었고 이를 자동화하기 위해 GitHub Actions를 활용해 보았습니다. GitHub Actions workflow 작성운영 중인 서비스의 구조는 monorepo 구조로 하나의 repository에서 3개의 서비스를 운영 중입니다. 해당 구조에 맞게 자동으로 Release와 Tag를 각각 생성을 해야 되므로 아래와 같은 조건이 필요했습니다.1. 각 서비스 배포 시 사용하기 위해 재사용이 가능2. commit message를 통해 versioning (but commit message에 version에 대한 내용이 없더라도 동작) 3. 배포 완료 시 Release..

사내에서 형상관리를 위해 GitHub을 사용 중인데 보안 이슈로 GitHub 2FA을 설정하게 되었습니다. 설정하면서 해당 내용을 간단히 정리하게 되었습니다. 2FA?2FA(2단계 인증)은 기존 비밀번호로 인증하는 방식 외에 다른 방식을 추가로 인증하여 접근하는 방식으로 GitHub에서는 23년 이후로 사용자들에게 2FA 설정을 권고하고 있습니다. GitHub의 경우 모바일 디바이스의 애플리케이션에서 생성하거나 문자 메시지(SMS)로 전송되는 코드를 이용하여 2FA 인증 형식을 사용합니다. 설정 순서GitHub에 로그인후 계정 Settings 메뉴에서 Password and authentication 메뉴로 들어갑니다. 해당 메뉴에서 2FA 항목에서 Enable two-factor authenticati..

현재 AWS S3와 CloudFront로 구성된 Serverless 인프라로 올라간 SPA에 SEO의 정보가 담긴 데이터를 가져와 적용하는 작업을 맡게 되었습니다. 람다 함수로 어떻게 SPA에 SEO를 적용했는지 팀 내부에 공유를 위해 문서 작성 겸 포스팅하게 되었습니다. AWS Lambda?AWS Lambda는 Serverless computing service로 별도의 서버 구성 및 관리의 필요성 없이 실행 시킬 코드를 람다 함수로 구성하여 필요할 때 함수를 실행시키는 서비스입니다. Lambda를 통해 따로 서버를 띄우지 않고 필요할 때만 함수를 실행시켜 사용한 컴퓨팅 시간만큼만 비용이 차징 되기 때문에 함수가 실행되지 않을 때는 차징 되지 않습니다. 작업 플로우변경할 SEO의 정보를 API를 통해..

FE 개발 배포 시 따로 웹서버를 띄우지 않고 인프라에 대한 관리 리소스를 줄이기 위해 serverless 인프라 구축을 하여 사용 중입니다. 이번에 개발팀 내에 공유하는 자리와 가이드 역할을 맡게 되어 해당 내용을 정리하게 되었습니다. 인프라 구성도 기술 스텍사용하는 기술 스텍을 간단하게 알아보고 인프라 구축 내용으로 넘어가도록 하겠습니다.AWS S3Amazon S3는 데이터를 버킷 내의 객체로 저장하는 객체 스토리지 서비스객체는 해당 파일을 설명하는 모든 메타데이터버킷은 객체에 대한 컨테이너(디렉토리)⇒ FE에서 build를 통해 만들어내는 산출물(bundle)을 올려두는 용도로 사용합니다.AWS CloudFrontAmazon CloudFront는 CDN 서비스콘텐츠 요청이 발생한 곳과 가까운 Edg..

팀 문화 중 코드 리뷰 문화를 개선하면서 코드 리뷰의 활성화를 위해 PR 진행 시 팀의 모든 인원을 Reviewer로 추가하기로 했습니다. 기존에는 팀장에게만 리뷰가 걸렸지만 코드 리뷰의 방식이 바뀌어 팀의 모든 인원을 계속 걸어줘야 하다 보니 번거로움이 생겼습니다. 그래서 PR 생성 시 자동으로 Reviewer가 걸리도록 Github Code owners에 대해 알아보고 적용하게 되어 해당 내용을 정리하게 되었습니다. Code owners?Github Code owners는 repository에 owner로 지정하여  PR 생성 시 지정된 owner들이 자동으로 Reviewer로 걸리게 합니다. Github Code owners 관리는 CODEOWNERS 파일로 하며 개인 또는 팀을 지정할 수 있습니다..

기존 FE 개발 환경을 공통으로 Vagrant을 이용하여 세팅된 VM에서 개발을 진행하다 이슈가 발생했습니다. Vagrant와 사용 중인 VirtualBox와의 버전 충돌로 인해 Vagrant 내부 소스를 수정하여 사용했고, 무거운 VM 작업 환경으로 개발 리소스가 낭비되었습니다. 그러한 불편함을 겪던 도중 Docker Container로 공통된 FE 개발 환경을 구축한다면 컨테이너의 장점을 살려 더 편하고 나은 환경을 구축할 수 있지 않을까?라는 생각이 들었습니다. 그렇게 시작된 Docker Container로 FE 개발 환경을 셋업을 시작했습니다. Docker 설정 1. Dockerfile 작성 및 이미지 빌드 기존에 사용 중이던 개발 환경의 경우 ubuntu 베이스의 node, git, yarn ..