(git & CI/CD) 닷넷은 공유/배포 전략이 복잡한 것같습니다.
페이지 정보
본문
컴파일 언어들이 다 이럴지 모르겠는데
닷넷은 특히나 git, github, 리눅스, 도커와 친하지 않습니다. 닷넷코어가 시작된지도 상대적으로 얼마 안되었죠.
닷넷은 여러앱이나 라이브러리를 하나의 솔루션으로 관리해서 IDE에서도 그렇게 열리고 멀티빌드&RUN이 됩니다.
예를 들어 api를 주고받는 두 앱을 동시에 RUN해서 테스트 해볼 수 있죠.
그렇게 밀접한 프로젝트(앱)끼리 같은 솔루션으로 관리하는데요.
그 프로젝트중에는 심지어 공통라이브러리로 빼는 프로젝트도 있습니다. 배포는 안하면서 다른 프로젝트에 참조되어 빌드타임에 포함됩니다.
거기다 관리해야할 문서도 있습니다.
CI/CD까지 생각하면 SDK와 런타임을 구분해서 도커파일도 멀티스테이지로 작성해줘야하고 말이죠.
이에대해 서브트리와 서브모듈을 사용하고 프로젝트별 CI/CD에대한 고민이 많습니다.
MSA 여러 애플리케이션(두개 이상)을 한 솔루션으로 관리한다면 그 독립적인것들을 단일 git 레포지토리로 관리할수가 없습니다.
하나 머지했다고 모든 프로젝트를 빌드해서 배포할 순 없으니 워크플로우 짤 래도 머리를 비틀어야합니다.
빌드할 필요없는 인터프리터 언어 단일패키지 프로젝트 (php등)에 비해서 매우 복잡해집니다.
도커파일도 복잡하고, 워크플로우 복잡하고, git은 안그래도 어려운데 서브트리/서브모듈도 관리해야해, API열면 API문서도 자동화하는데 품이 많이들고 말이죠. 각 단계의 복잡성이 높네요.
상황이 이렇다보니 DevOps 직군이 괜히 있는게 아니구나 싶습니다. 회사입장에서는 관리포인트가 늘어나고 인력비용증가가 따르죠..
이런걸 팀에서 누군가 주도적으로 하려고해도 이모든걸 이해시키고 강제하기도 무리일 것입니다.
혹은 말꺼낸사람이 총대메고 혼자 관리해야하는 지경에 이를테니 쉽게 도입이 안될 것입니다. 개발자가 솔직히 개발이나 하고 싶지 코드공유, 배포관리 하고 싶지 않으니까요.
여러단계에서 고민사항이 많다보니 베스트 프랙티스가 뭘까 의문이 드는데요.
MS나 MVP들이나 How-to에 주구장창 EF Core (ORM) 만 떠드는 것처럼 배포에 관해서도 마찬가지더라고요.
MS는 MS SQL과 Azure를 전폭적으로 밀고 있어서 IDE에 Azure 배포를 통합해놨습니다. 간단한 설정으로 클라우드 배포까지 되죠.
그러다보니 닷넷개발 입장에서 저리 복잡한 쇼를 해야하는 리눅스진영의 CI/CD전략을 잘 쓰지 않는 것같습니다. 아니, 커뮤니티차원에서 고민과 공유가 적은 것같습니다.
닷넷코어(이제는 그냥 닷넷)에 들어서서 오픈소스 친화를 천명했으나, 여전히 저런 복잡성과 MS의 밥그릇 (MS SQL, Azure) 문제로 갈길이 먼 것같네요.
순수개발로 그냥 뭐 만들기엔 닷넷 좋긴한데요. 특히 취미로 뭐 개발하기엔 이만한게 별로 없네요.
개발 방식이 닷넷과 비슷한 Java도 아마 상황은 비슷할 거 같은데 그쪽은 잘 모르겠어요.
KyleDev님의 댓글의 댓글
닷넷도 SPA였던 Blazor에 최근 SSR 지원되게 했거든요. 웃긴게 MVC나 Razor 페이지가 이미 동적생성이었거든요. 셋 다 razor 신텍스 쓰는 뷰파일들이고 말이죠.
그거 놔두고 굳이 Blazor에 SSR 넣어서 그거 권장하는데 SSR에 서버 인터랙티비티 섞어쓰고 프리렌더링이란게 있고 ..복잡성이 늘었거든요.
왜 굳이 힘들게 살아가게 만드는지(?) 모르겠습니다 ㅎ
얼인1님의 댓글
필요한 프로젝트에서 사용하고 있습니다.
배포는 gitlab action(..이 아니고 pipeline인가)에서 빌드해서
azure에서 app service로다가 서비스.
Realtime님의 댓글