포스트 작성의 불편함

깃헙 블로그를 만드는 도중, 블로그에서 글을 하나 쓰는 과정이 너무 귀찮다고 느꼈습니다. 당시 블로그에서 글을 하나 쓰고 발행하려면 아래와 같은 과정을 거쳐야만 했습니다.

1. node blog.js를 입력하여 블로그 메타데이터 업데이트 및 각 포스트의 jsx파일 생성
2. yarn build를 입력하여 React 빌드
3. unknownpgr.github.io리포지토리를 로컬에 clone
4. unknownpgr.github.io 리포지토리의 내용을 전부 지우고 /build디렉토리의 내용을 거기에 복사
5. git add .
6. git commit -m "Commit message"
7. git push origin master

...

좋지 않습니다. 글 하나 쓰려면 무려 7단계의 작업을 거쳐야 하며, 이중 하나라도 실패하면 글쓰기가 실패합니다. 특히 1번과 2번의 경우 Node.js를 설치해야만 가능한 과정인데, 저는 블로그를 사용하기 위해 git 이외의 다른 툴을 설치할 필요가 없었으면 좋겠다고 생각했습니다.

처음에는 블로그를 빌드해야 하니 Node.js는 어쩔 수 없이 필요하다고 생각했고, 그래서 blog.js가 위 과정을 전부 실행하도록 했습니다. 그런데 혹시 이것을 자동화할수 없을까 해서 열심히 구글링을 해본 결과, CI라는 개념을 알게 됐습니다.

Continuous Integration (CI)란?

도입 배경

Continuous integration이란, 이런 문제를 해결하기 위해 등장한 개념입니다. 제 블로그의 경우 저 혼자 관리하는 프로젝트이고, 하나의, 많아 봐야 두 개 정도의 개발 환경에서 개발이 이뤄집니다. 그런데 만약 규모가 큰 IT기업에서 이런 절차가 필요하다면 어떻게 될까요?

기본적으로 여러 사람이 프로젝트를 진행할 때에는 하나의 코드 베이스가 존재하고, 이것을 복사하여 개발을 수행하게 됩니다. 그런데 개발을 완료하고 나면, 아마도 다른 개발자들이 코드 베이스를 수정해서 코드 베이스가 바뀌어있을 것입니다. 그러므로 내가 작업한 내용을 코드 베이스에 통합하기 위해서는, 코드 베이스의 변경된 내용을 다시 pull하여 가져올 필요가 있습니다. 이때, 코드 베이스에서 달라진 내용이 많다면 통합하기 위해서 해야 할 수정들 역시 많이 생길 것입니다. 이렇게 하다 보면, 코드를 작성하는 데 드는 시간보다 코드를 병합하기 위해서 드는 시간이 더 길수도 있습니다. 특히 개발 환경과 빌드 환경이 다르다면? 환경 맞추는 것부터가 귀찮은 일임이 분명합니다.

기껏 공들여서 병합해놨더니, 빌드하던 중 오류가 발생합니다. 블로그같은 가벼운 프로젝트는 빌드하는 데 1분 30초면 충분하지만, 기업에서 운영하는 아주 큰 프로젝트는 빌드하는 것이 시간 단위로 걸릴 텐데, 오류가 나면 그 긴 시간을 들여 새로 빌드해야합니다. 당연히 오류를 고쳐서 빌드가 성공할 때까지는 다른 작업을 전혀 할 수 없습니다.

거기다가 우아한 형제들 기술 블로그에서 잘 나와 있듯, 빌드 / 배포 과정이 복잡할 경우 Human error의 가능성이 높고, 빌드가 끝나고 나면 테스터에게 알림을 보내서 베타 테스트 요청을 해야 합니다.

이 모든 과정은 프로젝트의 개발을 더디게 만들고, 부가적인 노동력을 필요로 합니다,

CI의 작동 방법

그래서 CI라는 개념이 등장합니다. Continuous Integration이라는 이름에서 알 수 있듯, CI는 이 모든 통합 작업을 자동화해주는 것을 의미합니다. 예를 들자면 다음과 같이 CI를 구성할 수 있습니다.

1. 개발자는 개발을 한 후 특정 branch에 PR를 보냅니다.
2. 그러면 CI 서버에서 자동으로 이를 인식, 유닛 테스트를 수행합니다.
3. 만약 테스트를 통과하면 그때 merge를 하게 되고, 이후 자동으로 build가 이뤄집니다.
4. Build가 성공하면 테스터에게 자동으로 알림이 가고, 테스터는 빌드된 결과물을 테스트하여 문제가 있는지 검사합니다.
5. 아무런 문제가 없다면 배포합니다.

이러한 자동화를 통하여 개발-통합-테스트-빌드 사이클이 효율적으로 운용될 수 있습니다.

깃허브 블로그에서의 CI

제 프로젝트는 깃허브 블로그일 뿐이고, Unit test라 할 만한 것도 없습니다. 사실 React build가 이뤄지기만 하면 아무런 문제가 없는 것으로 간주할 수 있습니다. 그러므로 다음과 같은 CI과정을 설계했습니다.

1. master branch에 push event 발생하면 시작
2. blog.js를 수행하여 포스트 오류 정정 및 블로그 메타데이터 업데이트 / JSX파일 생성
3. 만약 포스트 오류 정정한 내용이 있다면 이를 commit 후 push
4. 블로그 빌드
5. 만약 블로그 빌드가 성공한다면 unknownpgr.github.io에 배포
6. 위 과정이 끝나면 성공, 실패 여부를 slack app을 통하여 알림.

위 CI 과정은 Github에서 제공하는 Action을 통해 이뤄집니다. 간단히 프로젝트에 .github/workflows 디렉토리를 생성하고, YAML형식의 workflow를 작성하면 알아서 실행됩니다. 제가 구성한 workflow는 아래와 같이 동작합니다.

1. Master branch에 커밋 메시지에 post-update라는 문자열이 포함된 commit이 push되면
2. checkout을 수행하고
3. 프로젝트 초기화(yarn install)를 한 후
4. node blog.js를 실행하여 업데이트한다.
5. 실패하면 slack으로 알림
6. 만약 포스트 오류 정정 내용이 있을 경우 현재 리포지토리에 commit 후 push
7. 업데이트한 내용을 build한 후
8. 실패하면 slack으로 알림
9. unknownpgr.github.io리포지토리를 위한 새로운 디렉토리를 생성한 후
10. git init 및 git pull을 수행하고
11. build 디렉토리를 새로운 디렉토리로 복사한 후
12. commit 후 push한다.

결론

위와 같은 CI를 구성한 결과, 포스트 작성 과정이 아래와 같이 단순해졌습니다.

1. git pull;git add .;git commit -m "Commit message"의 내용을 담고 있는 스크립트를 실행, 혹은 직접 입력
2. Slack의 알림이 올 때까지 기다리기

이후 성공했다면 Publish된 포스트를 보고 문제가 있는지 검사하고, 실패했다면 원인을 찾고 디버깅하면 됩니다. Node.js를 사용한 빌드는 모두 GitHub action에서 제공하는 ubuntu docker에서 이뤄지므로, 블로그를 사용하기 위해서 git을 제외한 어떤 프로그램도 설치할 필요가 없습니다.