.NET 개발자로서의 협업 - 2

• 배포

10년도 넘은 이야기를 하자면, 홈페이지를 만들면서 알바하던 시절 (다시말해, 제로보드를 이용한 홈페이지를 만들어서 찍어내던 시절)에 배포라는 개념은 현재까지도 널리(?)사용되는 FTP 를 이용한 배포였었다. 닷넷이라는 플랫폼으로 오면서부터는, FTP 배포보다 더 무식한 방법인 RDC를 이용해 CTRL+C / CTRL+V 였었음. 이미 자동화된 배포를 경험한 사람들(최근 리눅스쪽은 Docker, 닷넷쪽은 Jenkins 나 TeamCity)이라면 놀라자빠질 방법이겠지만, 의외로 실무에서 이렇게 배포하는 곳이 여전히 많다. (겨우 네트워크 드라이브 연결해서 기존 배포본 백업/변경 바이너리 카피의 단순 작업을 배치라던가 각자의 사정에 맞게 작성한 프로그램으로 하는 정도의 자동화는 되어있는 곳도 있음)

그간 경험한 배포방법을 보자면

1. FTP를 이용한 배포
2. RDC를 이용한 배포 (커스텀화 된 자동화 툴 포함 -_-)
3. 웹패키지 인스톨러를 이용한 배포
4. CI를 이용한 배포

정도인데, 웹패키지 인스톨러를  이용한 배포는 일본에 있던 시절 처음해본 방식이다. 이는 웹어플리케이션 프로젝트를 배포패키지로 생성하고 이를 셋업 프로젝트로 묶어서 배포하는 방식인데, 나름 훌륭한 방식이었던 것으로 기억된다. (단, 배포판을 만들기 위해서 은근 노가다를 해야하는것이 최대 단점) FTP 나 RDC 를 이용한 방식보다 참조 바이너리의 누락 혹은 무결성에 대한 보장이 어느정도 가능한 방식이었고, 간단한 IIS 설정까지도 컨트롤이 됐기 때문에, 클라이언트들은 굉장히 좋아했다.

그러다 CI 를 접하게 되고, 이제 배포는 CI 없이는 상상도 할 수 없는 지경에 이르렀다.

가장 처음 접한 CI 는 TeamCity였는데, 훌륭한 UI 를 제공하고, 사용자 입장에서 굉장히 편한 툴이면서, 일단 믿고보는 JetBrain에서 만든 툴이라는 점이 가장 큰 장점. 단점으로는 우선 유료라는 점! 뭐하나 회사에 요구하려면 잉여 취급받는 개발자 직군이라 유료버전 구매해주세요라고 당당히 말하기가 꺼려지므로(사실 이것저것 이 툴이 왜 필요한지 설득하고 이해시키는것이 더 어려움) 우선은 배포주기가 길고, 빌드수가 많지 않으며, 배포 서버수가 적은 백오피스단에서만 사용중에 있다. Professional Edition이 무료버전인데, 구성 가능한 빌드수가 20개로 제한적이고, 3개의 빌드 에이전트를 제공하고 있다. 소규모에 이정도면 충분히 훌륭하다고 생각하고 있지만, 빌드 구성이 50개가 넘어가는 시점에서는 좀 무리가 있다.

그러다가 귀차니즘을 끊어내고, 기존의 TeamCity의 빌드구성을 Jenkins로 마이그레이션하게 되었는데, 제한없는 빌드아이템. 훌륭하고 다양한 플러그인. 노드 관리를 통해서 자원만 허용한다면 에이전트를 무한히 확장 가능. 파이프라인 지원등 이 모든것이 무료라는 점이 가장 큰 매력이었다. 하지만, 닷넷 플랫폼 빌드를 위해서 기본적으로 필수 플러그인(MSBUILD,NUGET)을 제공해주던 TeamCity와는 달리, 개별적으로 플러그인을 설치해야 비로소 빌드구성이 가능하고, 닷넷관련해서는 은근히 참고할 만한 도큐먼트나 가이드들이 충분하지 않다는게 좀 힘들었던 것 같다.

어쨌든, 현재는 관리하는 전체 프로젝트가 넘어간 상태는 아니지만, 중요 프로젝트들은 Jenkins로 모두 넘어간 상태이고, 총 60개의 빌드잡을 운영하고 있지만, 더 적은수의 빌드잡을 운영하던 이전보다 배포주기가 짧아졌으며, Dev/Stage서버의 배포작업들이 분리되어, product 배포에 종종 발생하던 프리징이 사라지는 결과를 얻었다. 이는 단순히 TeamCity -> Jenkins로의 툴을 변경함으로써 만들어진 결과라기 보다는, 앞서 포스팅한 브랜칭 운영관리를 좀 더 적극적으로 도입함으로써 얻은 결과라고 생각한다. (결과적으로 SVN->GIT, TeamCity->Jenkins의 콜라보레이션으로 얻은 산물)

Jenkins로 닷넷빌드 + 배포 구성을 하면서 시행착오를 겪었던 몇가지 팁(?)을 적으면서 글을 마무리 하고자 한다.

1. 글로벌 변수를 최대한 활용할 수 있도록 공통으로 사용하는 값들을 관리하자
2. Shared Workspace 플러그인 사용으로, 공간 낭비를 최소화하자
3. dev/product 배포시 무결성을 위해 반드시 nuget 패키지 복원 config 는 별도 운영하자(자체 nuget 운영중일때 한정)
4. 보관 빌드 수는 자주 배포되는 잡 기준으로 15개 정도로 하고, 산출물(artifact)은 별도의 서버로 운영하여 롤백잡에서 활용하도록 하자
5. 클래스 라이브러리(nuget 배포용), 웹패키지 (web 배포용)으로 MSBuild 구성을 분리하고, dev/product 도 역시 분리하자
6. Slack Integration을 적극 활용하자