[02/17] 게더타운, 개발 스터디 ( CI/CD, Git flow, 테스트 )

 

 

 

매주 목요일 개발 스터디를 진행하고 있습니다.
5명이 진행하며, 코로나 때문에 게더타운에서 진행 한 지 벌써 두 달이 다 되어가고 있습니다.

당연시 여기는 개발 지식이나 서로의 회사에서 사용하는 개발방법론 등을 가지고 이야기 나눕니다.
오늘은 대략 10가지 정도의 주제를 가지고 이야기를 나누었는데요.

그 중에서 기억이 남는 내용을 가지고 정리를 해봅니다.

1. CI/CD의 대해 설명해보자.

CI/CD를 정의할 때, 우리는 CI 까지만 구축되어 있어! 혹은 CI/CD 모두 구축되어 있어라고 간혹 개발자들 사이에서 듣게 되는 용어입니다.저도 역시 이 용어의 범위가 매우 헤깔렸기에, 대화들이 기억에 많이 남습니다.

CI는 지속적인 통합, CD는 지속적인 배포를 의미하며 통합과 배포의 자동화를 의미합니다. 저는 최근 사이드 프로젝트를 진행하며, devops를 담당한 지인이 bitbucket pipeline을 통해 CD까지 한다는 이야기를 들었고, 실제로 최근에는 github의 action, bitbucket의 pipeline으로 CD까지 한번에 진행이 가능하다는 이야기를 들었습니다.

그렇다면 jenkins로 소스를 git에서 pull받아 jar로 빌드하고, 리눅스 명령어로 배포하는 과정도 CI/CD로 볼 수 있을까? 라는 의문의 들었습니다. 작은 범위로는 그 역시 CI/CD로 볼 수 있겠구나? 라는 생각이 들었지만, 엄연히 따지면 아닐 수도 있다라는 생각을 해봅니다.

그렇다면 CI/CD는 어느 시점에 더 중요해질까? 고민을 해보았습니다. 프로젝트의 규모가 크고, 배포하는 서비스 갯수가 많을 때? 예를 들어 글로벌 서비스이거나 도커/쿠버네티스를 이용한 msa구조로 서비스 단위로 쪼개는 모듈화 작업이 들어갔을 경우 더 중요하지 않을 까 생각합니다. region별로 라이센스 별로 등등... 각각의 이유로 배포자동화는 매우 중요한 요소가 될 것 같습니다.

CI/CD에 대한 이야기를 하며, 현재 근무하고 있는 회사에 대해 아쉬운 점도 생겼습니다.
최근 배포자동화에 대한 검토를 진행하며, 리눅스 서버 내에 DB를 설치하고 jdk를 설치하는 과정을 배포자동화라고 이야기하고 있었고,
인프라관련 설치 업무도 배포자동화의 영역이라고 부르기도 하나? 라고 의문을 가지는 시점에 용어에 대한 정리를 하다보니

CI/CD는 소스를 push한 후 부터 테스트, 배포까지 자동화하여 생산성을 증대하는 작업까지를 의미
( 인프라의 경우 배포자동화의 영역으로 일반적으로 생각하지 않는다! )한다고 이야기하고 있었기 때문입니다.

https://www.youtube.com/watch?v=UbI0Q_9epDM

CI/CD 정의를 유튜브로 찾아보니 해당 영상이 참 재밌게 이야기 해주고 있어, 추후 다시 보고자 유튜브 영상도 등록해봅니다.

2. Git Flow 적용.

git flow에 대한 이야기도 꽤 오랜시간 이야기했던 것 같습니다. feature, release, hotfix 등을 이용하여 master, develop, release 브랜치 등을 나누는 branch 전략에 대해 이야기 나누었는데요. 일반적으로 우아한 형제의 git flow의 이야기를 하게 되더군요.

사이드 프로젝트 스터디에서 전략을 짤 때 우아한 형제의 git flow로 이야기를 나누었던 기억이 납니다.
저 역시 이전 회사에서 우아한 형제와 같은 전략을 사용하도록 브랜치 전략 체계가 잡혀 있었기에 해당 방법이 눈에 들어오는 부분이 많았습니다.

https://techblog.woowahan.com/2553/

이 이야기를 하며, 현재 저희 회사의 소스관리에 대해서도 공유해보았는데요.
 사이트를 확산하는데 마지막에 master 브랜치로 머지 할 수 없는 형태로 사이트 별로 일부 코드들이 다른 경우 어떻게 관리해야 하는가?에 대한 고민이었습니다.

현재는 마스터 branch 만을 가지고 관리하는 형태로 되어 있지만, 소스 관리를 좀 더 잘 해보자는 needs가 있는데... 이 부분을 어떻게 해결해 나아갈 수 있을지... 여전히 저는 미궁입니다.

 

3. 단위테스트 / 통합테스트

단위 테스트, 통합 테스트 를 어떻게 진행하는 지에 대한 이야기를 진행했습니다.

단위 테스트의 경우, Junit과 mock을 이용하여 단위별 기능을 정의하고 테스트하는 과정을 의미하고, 통합테스트의 경우 모든 라이브러리 및 전체의 서비스를 통합한 테스트 과정을 이야기 하는데 각자의 회사에서는 어떻게 진행하고 있는 지에 대해 이야기를 나누었습니다.

공통된 의견으로 팀에는 테스트 코드를 중요시 하는 사람이 있고, 중요시 여기지 않는 사람이 있다는 점이었고, 테스트 코드 작성을 시간의 비용으로만 간주하는 경우가 많아, 테스트 코드를 작성하는 문화가 형성되지 않는 한 실제로 업무에서 적용하기는 매우 힘들다는 이야기였습니다.

저 역시 현재 회사에는 테스트 코드를 작성하지 않는 문화에 가까워 아쉬운 점이 많았는데, 역시나 저 혼자만의 고민은 아니었습니다. 결론만 놓고 보았을 때, 업무내 개발에서의 아쉬움을 채우기 위해 스터디를 진행하고 있지만..
이러한 아쉬움들 때문에, 많은 개발자들이 좋은 개발 문화가 있는 회사로 움직이려는 것 같다는 결론을 냈습니다. 결론이 참 아쉽습니다..

 

다음 시간에는 일부 이야기 하다만 DDD에 대한 내용을 이야기 나누고
프로젝트 패키지 구조 / 아키테처 구조 에 대해 일부 학습 후 이야기를 나누어 볼 예정인데요!

다음 스터디를 통해 가려운 부분들이 좀 더 명확해 질 수 있으면 좋겠습니다.