CI/CD를 구축하며

다음에 CI/CD를 구축할 때 도움이 되고자 시행 착오를 적는다. 

시행 착오

• 기존 코드가 완전한 코드라고 생각하지 말자.
  
  • 서버 자체를 백업하고 비교하라
    • 수동 배포가 진행되었던 서버 내 부산물들의 형상 관리가 되지 않았다.
      • 바람직한 SW는 소스 코드 기준으로 빌드/배포 되어야 한다.
      • 하지만 온프레미스 방식의 배포를 하는 경우 기존 서버에 특정 바이너리만 바꿔 끼우는 형식으로 작업이 진행되기에 바이너리를 제외한 다른 구성요소들은 형상 관리가 되지 않았다.(예를 들면 tomcat 등)
      • 업데이트가 자주 되지 않는 스크립트의 경우 GIt으로 부터 복사되지 않고 사용되었다.
      • 심지어는 Git에 형상이 존재하는 스크립트도 서버의 내용과 달랐다.
    • 수동 배포에 쓰였던 빌드/배포용 서버에 서버 종속적인 내용이 존재했다.
      • CI/CD를 구축하며 빌드용 서버나 배포용 서버를 따로 만들게 된다.
      • 기존 수동 배포에 사용된 빌드용 서버와 배포용 서버에서 스크립트 실행에 있어서 특정한 디렉토리 구조가 필수로 존재하여야 하거나, 서버 내에 특정 스크립트가 독점되어 있었다.
  • 항상 AS-IS 릴리즈와 테스트 케이스가 정상임을 확인 후, TO-BE를 확인하는 습관을 들이자.
    • A라는 검증계 브랜치로 CI/CD 관련 커밋이 적용된 후 경로탐색 Error가 났다.
    • 알고 보니 A브랜치는 CI/CD 커밋과 무관하게 경로 탐색 Error가 존재했다.
• 방화벽 해제는 가장 빠른 시일에 시작하여도 부족하다.
  • 높은 직급에게 도움을 요청하자
    • 우리 회사에 국한되는 이야기인지는 모르겠으나, 방화벽은 수 많은 절차, 부서, 협력사 간 얽혀있고 중간 단계가 많다.
    • 방화벽 해제를 이 모든 것들을 뜯어보며 해결하는 것을 굳이 추천하지는 않는다. 빠른 방화벽 해제가 필요할 때 각 단계별로 연락을 드릴 담당자들을 알게 되기는 하나 관련 업무 지식이 늘어나지는 않기 때문이다.
    • 이럴 때는 부서와 협력사들에게 입김을 불어줄 수 있는 같은 팀의 높은 직급 사람에게 도움을 청하는 것이 효율적이다.

CI/CD 구축에 중요하다고 생각하는 점

• 커뮤니케이션
  • CI/CD는 개발과 운영을 아루는 만큼, 양쪽의 커뮤니케이션이 중요하다.
    • 개발 인력들에게 빌드 스크립트를 전달 받거나, 다양한 파이프라인을 구성하기 위한 정보들을 공유받아야 한다.
    • 운영 인력에게도 기존에 배포를 어떻게 진행했는지 (예를 들면 필요 방화벽, AWS의 경우 CDK를 호출하는 스크립트나 관련 profile) 를 전달받아 파이프라인에 녹여야 한다.
  • CI/CD 관련 시스템을 알고 있는 사람과의 커뮤니케이션도 중요하다.
    • 고객사의 시스템을 통해서 CI/CD를 구축했다. 고객사 PM은 나와 마찬가지로 CI/CD 구축이 처음이었고, 원하는 그림만 말해주었기 때문에 실제로 고객사의 '시스템 관리자'와 커뮤니케이션 하며 구축해야 했다. 당연하게도 고객사 시스템 admin 권한이 없었기에, 시스템에서 어떠한 기능을 제공하는지, 각 기능에 어떤 권한이 필요한지를 알기 힘들었고 고객사와 지속적으로 커뮤니케이션을 이어가야 했다.
    • 사내 CI/CD 시스템을 관리하는 팀에도 많은 도움을 받았다. 해당 팀은 다른 팀의 CI/CD를 구축하여 주었지만 우리 팀은 스스로 구축하였다. 나는 Quality Gate (PR이 생성될 때, 정적 검증이 수행되어 결과에 따라 Merge하는 제한하는 부분)의 구현이 어려워, 해당 팀에 script 코드를 공유해달라고 요청했다가 거절 당하기도 하였다. 하지만 우연히 우리 팀에 요청이 오는 일이 있었고, 해당 일에 적극적으로 대응하며 친밀감을 쌓았고 지속적으로 모르는 점을 물어볼 수 있었다.
  • 이번 기회를 통해 SW시스템마다 Community가 존재한다는 사실을 알았다(ex. Bamboo Community). 생각보다 구글링한 블로그를 보기 보다, 해당 Community에 올라온 Q&A가 연관 단어 단위로 찾기 쉬웠으며 궁금증을 해소하는 경우가 많았다.
• 개발자의 편리함
  
  • 더 편리한 사용에 대한 고민이 필요하다.
    • 원하는 Branch의 정적 검증을 수행할 수 있는 Plan을 만들고 사용법을 공유했다. 문서에 사용법을 적어 공유하였지만 어떤 개발자 분이 정적 검증을 내게 직접 돌려달라고 두어번 요청을 했다. 마지막으로 정적 검증을 돌리며 다음에 같은 요청이 오면 '내 Role은 자동화 파이프라인을 만드는 것이지 각각의 파이프라인을 동작시키는 것은 아니다. 사용법 링크를 드릴테니 참고하여 사용하시라' 라고 말할 생각이었다.
    • 하지만 다시 생각해보니 나 스스로는 간편하게 만들었다는 생각했지만, 더 간편하게 만들었다면 개발자가 내게 일일히 요구했을까 싶었다. Bamboo의 기능을 더 공부해보며 개발자가 더 편리하게 사용할 수 있는 방법을 고민했다. CI/CD는 개발자가 더 자주 실행시켜 결과를 쉽게 볼 수 있을 때 가치가 높아질 것이라고 생각한다.