Devops란?

• Development + Operation 을 합친 말로, 개발하면서 부수적으로 필요한 업무를 개발과 같이 합쳐서 개발의 효율성을 높이는 방법이다. 개발 중에 번거롭게 반복 되는 작업을 자동화 하고 빠르고 빈번한 배포를 하기 위해 진행 된다. 애자일이나 스크럼 같은 방법론이 나오면서 보다 빠른 배포 주기를 갖기 원했고 이를 위해서는 당연히 더 잦은 배포를 위해 시스템화가 필요했다. 그렇기 때문에 이를 수동으로 하기 보다는 자동화해서, 개발자는 전체 개발 프로세스 중에 개발에 좀 더 집중할 수 있도록 도와준다.

Devops 경험

• 꽤 오랫동안 회사에서 DevOps 작업을 했다. 처음에는 내가 필요해서 하기 시작했고, 차츰, 서브 태스크로 일하게 되었다.
• 그러면서 개발자가 많이 참여하는 큰 프로젝트에서도 DevOps 태스크를 하게 되었고, 이 글을 그런 경험들을 한 번 정리해 본 것이다.
• 다소 개인적인 내용도 담고 있고, 호불호가 갈리는 제품도 있을 꺼 같다. 내용적인 오류가 아니면 그냥 읽어주길 부탁한다.

전체적인 Flow

• 보통 코드를 작성할 때, 로컬 PC에서 개발을 시작한다. 그리고 코드를 형상 관리 툴에 머지를 하고 빌드 결과를 확인하고 산출물을 받아 테스트를 진행한다.
• 다만 여러 사람이 같이 공동으로 개발하는 리포지토리에서는 한 사람의 개발자가 다른 사람의 개발을 방해할 수 있다. 그렇기 때문에 보다 신중하게 개발해야 하고 이런 방해를 미리 막기 위해 여러 시스템이 존재한다.
• 그 시스템 중 하나가 DevOps의 주요 기능이다.
• 큰 Flow는 다음과 같다.
  • 코드 작성 : 개발자가 코드 작성을 하고 형상 관리 서버에 올린다.
  • Presubmit Test : 코드가 서버에 올라가면 Lint나 기본적인 Commit message 등을 확인한다. 오탈자를 찾거나 머지가 될 수 있는지 확인을 한다. 빌드 테스트로 진행해서 미리 빌드 에러가 발생하는지 확인한다. 만약 여러 빌드 환경을 제공한다면, 각 플랫폼 별로 빌드 테스트를 진행한다.
  • Review : 코드 Owner나 동료가 코드리뷰를 진행한다. 피어 리뷰로 문제가 없으면 +2 또는 LGTM을 줘서 리뷰가 마쳤음을 확인한다.
  • Pre Landing Test : 리뷰를 마치면 코드를 Landing 하기 위해 테스트를 진행한다. Merge에 문제가 없으면 코드를 Landing 시키고 문제가 있으면 Author에게 노티를 보낸다. 코드와 관련 된 부분에 대해 Unit 테스트를 돌린다. 필요하다면 간단한 성능 테스트나 기능 테스트도 같이 수행한다. 만약 여러 플랫폼에 영향을 미친다면 관련 된 플랫폼 테스트를 진행한다. 경우에 따라서는 정적 분석도 수행한다.
  • Post Landing Test : 이제 코드가 Merge 되었다. Merge 된 기능에 대해서 Unit 테스트를 진행하거나 프로젝트의 전체 테스트를 진행한다. 성능 테스트나 시간이 오래 걸리는 Fuzzy 테스트도 진행을 한다. 테스트 결과에 문제가 없다면 산출물을 배포한다.
  • Bot : 필요에 따라서 Test Agent를 멈추거나 다시 동작 시킬 수 있다. Flaky 한 테스트가 많아서 테스트가 계속 실패한다면 Merge를 잠깐 멈추고 해결할 수 있도록 도와준다.
  • Artifacts : 산출물과 디버그 심볼을 같이 모은다. Intersection Test를 진행할 수 있도록 산출물의 CL 번호 및 날짜는 정리한다.

DevOps 개발 경험

• 빌드는 당연히 빠르면 빠를 수록 좋다. 빌드 속도가 빠르면 개발도 더 빨리 진행 되고 많은 사람의 시간을 아낄 수 있다. PC 성능은 당연히 제일 좋은 거 써야하고 빌드는 CPU Core 수 > 램 > SSD 순으로 중요하다. SSD라고 빌드 속도가 엄청 빨라지는 것은 아니고 램은 링킹 같은 많은 메모리를 필요로 할 때 중요하다. 하지만 대부분은 CPU Core 수에 따라 빌드 속도가 줄어 든다. 만약 Cache / Cache 서버를 쓴다면 더 빨리 빌드 할 수 있다. (cache/scache/sccache/sstate-cache) 가급적이면 20~30분내로 빌드 되는게 가장 좋다. 아니면 최소한 작은 모듈로 나워서 모듈 빌드가 되게 끔하는게 좋다.
• 모듈 빌드가 잘 되게 하려면 CMake나 ninja, gyp, meson 등을 잘 알 필요가 있다.
• 한 프로젝트에서 많은 repository 를 나누는 것을 좋아하지 않는다. 간혹 기능마다 repository를 만드는 경우가 있는데, repository 하나 만들 때 마다 관리하기 매우 어렵다. 코드마다 Sync를 맞춰야 하는데, 그 비용이 생각보다 크다.
• repository를 나누는 기준은, 관리할 수 없는 third party일 경우, 어딘가에서 공용으로 사용한 repositry인 경우, private 코드와는 별도로 외부에 open해야 될 필요가 있는 코드일 경우를 제외하면 한 프로젝트에서 repository를 나누는 것은 지양해야 한다.
• git submodule 보다는 별도의 sync 코드를 만드는게 편하다. 전체 repository를 다 관리할 수 있는 스크립트가 있으면 좋다.
• 브랜치 관리는 그냥 평범하고 심플하고 일반적으로 하자. 그리고 굳이 필요없는 브랜치는 만들지 말자 그리고 필요 없으면 쌓아두지 말자.
• DevOps 관련 되서는 웬만하면 있는 솔루션 사서 쓰자. DevOps 관련 툴 개발하는 회사가 아니라면, 본인 프로젝트 개발하는데 더 노력하자.

사용한 툴

• Scripts
  • python : 어떻게 보면 DevOps 기준으로 bash를 대체하는 최고의 스크립트 아닌가 싶다.
  • bash : 짧게 쓰기에 좋은 스크립트, 가독성은 python이 난 더 좋다.
  • Powershell : 윈도우 PC에서 아무것도 설치 되어 있지 않은 상황에서 배포하기 좋은 스크립트다. 그 외의 경우엔 언제 쓸지 모르겠다.
• SCM
  • SVN / CVS : 옛날 코드 형상 관리 툴, 그때는 너무 편했는데 지금 쓰라면 못 쓸꺼 같다.
  • Source Safe : MS 사의 코드 형상 관리 툴, 누군가 Check out 하고 가면 머지를 못하는 단점과 사람 관점이 아니라 코드 관점의 Checkout/in으로 항상 헷갈려했다.
  • P4 : 빠르고 GUI도 제공하지만 이제는 더 이상 못쓰겠다. 바이너리 리소드에는 좋은 듯 싶지만.
  • Git / Hg : Hg는 비트버켓의 공식 툴이었던 적이 있어서 짧게 써봤지만 Git과 유사하다. Git은 이제 코드 형상 관리의 표준인 듯. 토발즈 만세.
• Build Tool
  • Quickbuild : 갠적으로 비추인 빌드툴, groovy라는 언어를 사용하고 괴상한 UI 상속 시스템을 갖고 있어서, 굳이 Quickbuild가 필요하면, 개인적으로는 젠킨스를 추천한다. groovy를 왜 선택했는지 알 수 없다. 가끔 버전이 다르면 다르게 동작한다. 이 때문에 종종 알 수 없는 에러도 나고, 심지어 테스트 하기도 어렵다.
  • Jenkins : 오픈소스고 지금도 꾸준히 사용 되고 있는 빌드툴, 많이 써보진 않았지만, 사용자가 많아서 개인용/사내용으로는 쓸만한 듯 하다.
  • Circleci : Travis / Github Action 처럼 YML 파일을 작성해서 CI를 돌리는 툴, Travis는 써 본적 없고 Github Action 은 최근에 써봐서 뭐가 더 좋은지 모르겠다. 작은 크기의 Docker Image가 더 많은 듯 하다.
  • GitHub Action : 가장 빨리 셋업하고 빌드 봇/에이전트가 필요하다면 가장 좋은 솔루션이긴 하다.
  • Gogs : Go 언어로 쓰여져서 빠르고 개인적으로 쓰기에 좋다. 개인이 셋업 하려고 한다면 GitLab 보다는 https://gogs.io/ 가 나을 듯 싶다.
  • GitLab : 초창기에 설치형임에도 Private으로 설치하면 레포지토리 제한이 있어서 비추. 그리고 나는 Ruby를 모른다.
• Issue Tracking Tool
  • Bugzilla : 쓰긴 썼지만 내가 셋팅한게 아니었고, 좋지도 나쁘지도 않았다.
  • Jira : 흠 너무 기능이 많고 너무 복잡하다. atlassian 의 노예가 되지 말자.
  • Trac : 지금도 개인적으로 사용하는 Tool이다. Python으로 작성 되어 있고 자체적으로 튜닝이 가능해서 사용한다. SVN/Git을 제공하며 Wiki와 버그질라 같은 이슈 트래킹 기능이 함께 있다.
• Artifacts
  • jfrog : 산출물 및 도커 이미지 관리에 사용 된다.
  • Azure feed : Azure Pipe를 통해 빌드 된 산출물을 저장한다.
  • Docker : 도커는 없으면 안된다. 옛날에 배포를 어떻게 하고, 온갖 툴을 어떻게 셋업을 했는지…