작업 일지#12 1차 배포

이 작업일지는, 기술적인 부분보다는 특정 결과를 얻는데 까지 겪은 과정과, 고민의 흔적을 남기고자 쓴 글입니다. 따라서, 기술적인 부분에 대해서는 다소 내용이 추상적일 수 있습니다.

 

 

이번에는 저번 일지에서도 언급했듯이, 배포 프로세스를 익혀보고, 익혀본 프로세스를 자동화하는 과정을 가져보았다. 배포 자동화를 하기 위해 github action을 사용해보았다. jenkins와 같은 ci툴을 활용하지 않은 이유는, 따로 ci 서버를 운영하는 것이 취준생으로서는 조금 부담스러웠고, jenkins의 사용법보다는 자동화 프로세스에 대한 나의 논리를 확립시키는 것에 더 집중하고 싶었다.

 

 

배포 자동화는커녕, 배포 자체를 스스로 해본 적이 없었기 때문에, 이번 작업은 점진적인 반복과 스스로에게 질문을 하고 그 질문의 답을 찾으며, 작업을 진행했는데, 과정을 요약해보면, 다음과 같다.

1. 왜 배포를 하는가? 나 자신 뿐만 아니라, 다른 클라이언트에게도 서비스를 제공하기 위해서다.
2. 왜 배포 과정을 자동화해야 하나? 반복되는 작업을 실수 없이 일관적으로 수행하여, 생산성을 높이기 위해서다.
3. 무엇을 자동화 해야하나? 전송하고 싶은 애플리케이션 코드 통합, 그리고 그 코드를 서버로 전송. 마지막으로 그 코드를 실행시켜야 한다.
4. 그 자동화를 수행 하려면 무엇을 해야 하나? 원격으로 서버에 접속할 수 있어야 한다. 그리고, 위에서 서술한 과정을 실행하는 trigger 역할을 하는 event가 필요하다.
5. 그 event를 발생시킬 수 있는 수단으로 무엇이 있는가? github에서 제공하는 webhook이 있다. 이 webhook을 사용하면, 전송되는 payload를 통해 각종 ci툴로 pipeline을 구축하여, 배포를 포함한 다양한 종류의 프로세스를 자동화할 수 있다.
6. 가장 보편적이고, 지금 내가 바로 사용할 수 있는 것은 무엇인가? 보편적인 툴로는 Travis CI, Jenkins, github action 등이 있다. 그중에서 바로 사용할 수 있는 툴은 github action의 workflow를 활용하는 것이다.

 

 최대한 줄여보면, 위와 같이 6가지로 요약해볼 수 있지만, 리눅스 환경에서 작업을 많이 해보지 않아, 익숙해지기 위해 했던 삽질이 가장 많은 시간을 소모했던 것 같다.

 

이 6가지를 통해, 현재는 'develop' 브랜치에 merge를 하면, 애플리케이션 코드의 통합 및 배포가 이뤄지는 과정을 자동화할 수 있었다. 그러나, 현재는 단일 서버에만 배포가 가능한 상태로 '확장성' 있는 배포 자동화를 구축하려면 아직 멀었다.

 

 그래도 이번 과정을 통해, 블로그를 그대로 따라 할 수밖에 없었던 내가 스스로 배포 프로세스를 생각해낼 수 있었던 점을 생각하면, 내게는 정말 큰 수확이었던 것 같다.

 

ps. https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow 를 통해, fork 리포지토리의 경우 secret 변수가 전달되지 않는다는 것을 알게 되었다.