레넌의 개발 일기

라벨별로 빌드를 유발해야하는 이유 우리팀의 Github 레포지토리는 백엔드와 프론트 파일을 함께 관리하고 있다. 따라서 어떤 파일이 수정되었던지 간에 상관없이 Develop 브랜치와 Main 브랜치에 PR이 머지되거나 Push가되면 프론트엔드 파이프라인과 백엔드 파이프라인이 모두 돌아가 불필요한 빌드가 실행되는 경우가 있었다. PR의 라벨에 따라 파이프라인이 돌아가도록 설정한다면 이 문제를 해결할 수 있을 것이라고 판단했다. 기존 설정 파이프라인의 빌드 유발을 설정할 때 보통은 GitHub hook trigger for GITScm polling을 많이 사용할 것이다. 이 설정은 깃허브로부터 Push 훅을 받았을 때 빌드가 유발되는 설정이다. 이 설정은 위에서 설명한 문제점이 있다. 라벨별로 설정하기 P..

CI 속도를 개선해야하는 이유 CI는 지속적 통합이라는 뜻으로, 개발을 진행하면서도 품질을 관리할 수 있도록 여러명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있음을 의미한다. 지속적으로 빌드와 테스트를 돌림으로써 통합되는 코드에 대해 문제가 없는지 확인하는 것이 CI의 중요한 요소 중 하나라고 생각한다. 따라서 빌드와 테스트에 대한 피드백 시간 또한 중요하다. 빠르게 피드백을 받게 된다면 불과 몇 초일지라도 개발자 조금이나마 편하게 개발을 진행할 수 있을 것이다. 기존의 Workflow 처음 공식 프로젝트에서 적용한 workflow 는 아래와 같다. name: gongseek backend CI # Workflow를 실행시키기 위한 이벤트 목록 # 모든 브랜치에 대한 PR이..

처음에는 CI/CD 도구로 비교적 간편한 CI/CD 도구인 Github Actions를 사용하려고 했지만, 우테코 Organization 권한 문제로 CD를 진행할 수 없었다. CI는 Github Actions로 진행하고, CD는 젠킨스로 진행하기로 했다. 간단하게 Github Actions에 대해 알아보려고 한다. Github Actiosn에서는 특정 레포지토리에 대한 PullRequest가 열리거나 Issue가 열리는 등의 이벤트가 트리거 되도록 workflow를 구성할 수 있다. workflow에는 1개 이상의 순차적으로 실행되거나 병렬적으로 실행되는 jobs를 포함할 수 있다. 각각의 job은 자체 virtual machine runner나 컨테이너 내부에서 실행된다. 구성요소 WorkFlow w..

문제점 Jenkins 파이프라인을 작성하다가 Host key verification failed 문제를 맞이했다. 처음에 작성한 파이프라인은 아래와 같다. pipeline { agent any stages { stage('Checkout SCM') { steps { checkout([$class: 'GitSCM', branches: [[name: '*/develop']], extensions: [[$class: 'SubmoduleOption', disableSubmodules: false, parentCredentials: true, recursiveSubmodules: true, reference: '', trackingSubmodules: true]], userRemoteConfigs: [[crede..

이전 게시글에서는 백엔드 파이프라인을 구성하는 방법에 대해서 이야기 해보았다. 이번에는 프론트엔드에서는 어떻게 파이프라인을 구성할 수 있을 지에 대해 알아보도록 하자. 파이프라인을 구축하기 전까지의 단계인 깃헙 토큰 설정, 웹훅 설정, Credentail 설정은 백엔드편과 동일하기 때문에 생략하도록 하겠다. (사실 파이프라인 과정도 크게 다르지 않다.) 설정 우리팀의 프론트에서는 리액트를 사용하고있다. 이를 빌드하기 위해서는 서버에 Node.js가 서버에 깔려있어야한다. 이를 위해 Jenkins에서 미리 설정을 해주어야한다. 이를 위해서 젠킨스에 NodeJS 플러그인을 따로 설치해주었다. NodeJS 플러그인이 설치되었다면, Jenkins관리 -> Global Tool Configuration 으로 들어..

젠킨스를 구축하는 과정에서 빌드를 끝마치지 못하고 서버가 죽어버리는 현상이 발생했다. 처음에는 무슨 문제인지 인지하지 못하였고 서버를 껐다 켜보기만을 반복하였다. Gradle 빌드의 문제인 줄만 알고 빌드의 속도나 의존성을 계속 봤었다. 하지만, 문제는 코드에 있지 않았다. 바로 메모리가 부족하기 때문에 발생한 일이었다. 우아한테크코스에서 제공해주는 인스턴스는 t4g.micro이다. 그렇기에 Memory는 1GB 밖에 되지 않았다. 1GB는 젠킨스 위에서 빌드를 돌리기에는 턱 없이 부족했던 것 같다. 따라서 이 문제를 해결하기 위해서 Swap Memory라는 것을 이용하였다. Swap Memory란? 실제 메모리가 가득 찼는데 더 많은 메모리가 필요로 할 때, 하드디스크의 공간을 가상 메모리로 대체하여 ..

Git Submodule 이란? Git Submodule은 메인(부모) 레포지토리에 하위(자식) 레포지토리를 두고 관리하기 위한 도구이다. 하나의 프로젝트에서 다른 프로젝트를 함께 사용해야 하는 경우 주로 활용한다. 사용 계기 프로젝트를 하면서 application.yml에 담기는 민감 정보들을 관리해야 할 일이 생겼다. 지금까지는 application.yml에 환경변수를 설정하여 직접 EC2에서 이를 처리했지만, Git Submodule이라는 좋은 방법이 있어서 해당 개념과 적용 방법에 대해서 작성을 해보려고 한다. 적용 과정 Repository 만들기 우선 submodule을 위한 레포지토리를 생성해야 한다. 다음과 같은 과정을 통해 생성을 하면 된다. 팀 organization 계정 생성 비밀 정보..

로깅이란? 로깅이란 시스템이 동작할 때 시스템의 상태 및 동작 정보를 시간 경과에 따라 기록하는 것을 의미한다. 로깅이 필요한 이유 개발 과정 혹은 개발 후에 발생할 수 있는 예상치 못한 애플리케이션의 문제 진단 가능 다양한 정보 수집 가능 사용자 로그의 경우 분석 데이터로 활용 가능 하지만 로깅을 하는 단계에서 적절한 수준의 로그 기록 기준을 잡지 못하면 방대한 양의 로그 파일이 생성되는 문제를 겪거나, 의미 있는 로그를 쌓지 못하는 경우가 발생할 수 있다. 결국 효율적으로 로깅을 하는 방법을 이해하는 것이 중요하다. 로깅하는 방법 대표적으로 Log4j 와 Logback이 있다. Log4j는 2015년 개발이 중단되었고, 현재 널리 사용되고 있는 Logback으로 설명하도록 하겠다. Logback은 S..