Gitlab CI CD Pipeline vs TFS and Manual

  • #3716412
    DevOps 73.***.131.168 800

    현재 회사는 웹어플리케이션과 오라클 패키지는 TFS 에서 최종 배포 버전을 다운받아서, 배포 유틸리티에 포함 시키는 형태입니다.
    대략 15년 넘은 구식 방식을 사용합니다. 그리고, 유닉스에 올리는 프로세스는 scp 를 이용해서 파일 전송 형태로 배포를 합니다.

    정말 구식이죠. 버전 콘트롤에서 많은 오류를 만들어 내고 있습니다.

    DevOps 부서장이(직원 700명 중소업체에서 디렉터라 큰 힘은 없고 한명의 CTO 가 실권을 갖는) 제가 와줬으면 해서 옮겼습니다.
    제가 있었던 프로젝트 뿐만 아니라 나머지 10여개의 타 프로젝트도 이런 식으로 변경 배포 작업을 있어서, 이걸 바꾸려고 합니다.

    본론으로, 질문은 Gitlab CI CD pipeline 을 활용하면, 유닉스 프로세스 배포, 웹어플리케이션 배포, 오라클 패키지 배포,
    수천대의 리눅스 우분투 기반의 터미널의 어플리케이션 배포 등이 일괄적으로 가능한지 궁금합니다.

    유투브, Udemy 맛보기 강의를 보면 bash 스크립트를 잡에 넣어서 pipeline 이 runner 를 실행시키는 모습만 보여주는데요,
    저희 회사처럼 리눅스/유닉스 뿐만 아니라 웹/오라클/윈도우즈 등 여러 환경의 프로세스 배포도 가능한지 가늠하기 어렵네요.

    Gitlab CI CD pipeline 방식으로 이렇게 다양한 환경에 서비스 배포가 안된다면, 가능한 상업용 솔루션이 있는지요.

    여러 배포를 통합 관리하고 싶은데, 좋은 방법이 있다면 소개 부탁드립니다.

    감사합니다.

    • cs 222.***.183.216

      가능은 할텐데

      수천대의 리눅스 우분투 기반의 터미널의 어플리케이션 배포 등

      이 부분의 용도가 궁금하네요

      • DevOps 73.***.131.168

        리테일에 들어가는 단말기들입니다. 보통 큰 주는 8000대 정도 이상, 작은 주는 1000대 이상입니다.
        화면 변경, 메뉴 변경, 기타 등등 때문에 터미널 어플리케이션도 업글이 1년 3,4번은 발생합니다.

    • Azure 50.***.19.170

      Devops가 아닌 개발자입장에서 궁금한게 왜 Azure cloud를 사용하지 않으시죠? Deployment, 버전 컨트롤, auto swap, monitoring 모든게 원샷으로 해결될거 같은데요. 패키지도 blob storage로 관리하구요. 혹시 예산때문인가요?

    • 74.***.155.53

      충분히 가능한데 Gitlab만으로 이루어 지는게 아닙니다. GitLab은 전체에서 한 부분입니다.

      구글 검색으로 DevOps 과 CI/CD에 관련 툴들을 리서치해보면 답이 나옵니다. 하지만 알아야 할것은 새로운 관련 툴을 회사에 도입하는것은 새로운 프로잭입니다. 그냥 다른 리눅스 명령어와 스크립으로 해결되지는 않아요.

      그리고 딱 이거다 하는것은 없고 본인의 상황에 맞게 도입하는겁니다.

    • 흠.. 68.***.3.209

      Azure 자체에는 글쓴이가 말하는 ci/cd 기능이 없지 않나요? Azure devops pipeline으로 따로 관리하고 트리거링하는 방식으로 알고있는데..

    • devops 98.***.127.198

      CI Tool 자체는 패키징 밑 테스트 로직을 각 종류의 배포마다 따로 짜셔야 하는건 어떤툴을 쓰던 어쩔수 없을거 같고,
      CD 중에 가장 많은 환경을 포용하는건 Spinnaker나 Octopus Deploy 이지 않을까 싶습니다.

    • Sil 174.***.2.154

      어짜피 리눅스 웹어플리케이션은 당연히 되겠고..
      오라클도 docker상에서 shell스크립트로 빌드 할수 있으면 될거 같고..

      어짜피 scp로 배포하면 대상이 리눅스던 윈도우던 상관없을것 같구요.. – cicd라고 배포방식은 다를건 없을것 같습니다.

      근데 수천대를 대상으로 일괄배포 한다면 에러는 날 수도 있을것 같은데.. – pos같은 단말기를 대상으로 한다면 꺼놓거나.. 네트웍에러가 나거나 하겠죠?

      스크립트 상에서 서버나 클라이언트 상에 현재 버젼을 기록하거나해서 이후엔 버젼이 낮은 단말기만 재배포하거나…
      리포트 기능으로 업데이트가 미완료된 장비를 따로 관리할수 있게하면 추가 관리가 좀 편해질것 같은데…

      근데.. 만약 개발단까지 수정이 가능하시면 배포 방식을 바꿔서 클라이언트가 aws s3등 서버에 올려진 업데이트 파일을 주기적으로 다운로드 받는 방식으로 수정하셔도 좋겠네요. – 클라이언트의 auto update라면 이 방식을 주로 쓰죠?

    • 지나가다 187.***.182.100

      Gotlab을 사용한다는 전제하에 간단히 말하자면,
      1. 각 프로젝트별로 클라우드 환경을 설정. PCF, Azure, GCP, AWS
      2. Girlab에 각 프로직트별 repo를 만들어서 버전컨트롤
      3. Gitlab 파이프라인을 이용해서 repo를 해당 클라우드로 전송
      4. 각 리테일 단말기는 각 클라우드로 연결해서 동작하는 웹기반으로 변경
      대충 이런 시나리오가 그려지네요.
      각 리테일 단말기는 웹기반 앱을 사용해도 rest api를 사용하면 인터넷 연결이 불가능해도 일단은 로컬에서 동작하도록 만들 수 있습니다.
      기본 데이터를 로컬에도 저장하는 방식으로 하면요

    • 와신난다. 192.***.111.180

      우리는 약 4만대의 리눅스 기반 서버를 운용하고, 서비스 소프트웨어는 자체 개발입니다. 그러나 OS를 포함한 시스템 소프트웨어도 관리해야 하므로, 전체적인 관리 시스템은 상당히 복잡합니다. 자체 소프트웨어 스택을 deploy하는 것과 시스템 update하는 것은 별개이면서도 연동이 되도록 되어 있습니다. 서비스를 계속 제공하면서 온라인 업데이트를 해야 하기 때문이죠.

      지금 여러가지 문제를 해결할려고 하시는데, 각 문제에 대한 분석과 목표를 먼저 구체화해야겠습니다. 어떤 CICD 솔루션을 던져 넣는다고 모든게 해결될거라고는 생각하지 않으시죠? 절대로 그렇게 안됩니다. 이런 툴들이 다양한 이유는 각각 특정 문제 해결에 집중하기 때문이기도 합니다.

      버젼 콘트롤을 포함한 소프트웨어 개발 프로세스, 빌드 및 QA/testing에 먼저 적절한 엔지니어링 프로세스가 자리 잡혀야 합니다. 프로세스는 너무 rigid하면 발목을 잡을 수도 있으니, 적절한 타협점이 필요합니다. 역시 주요 문제 해결을 시작점으로 해야겠죠.

      deploy 문제는, scp로 한다고 했는데 그것 자체가 근본적인 문제인가요? 이런 push model과 pull model은 장단점이 있습니다. 요즘은 많은 deploy 툴들이 pull하도록 되어 있죠. 그렇다고 그게 무조건 좋은 것도 아닙니다. 중앙에서 각 시스템의 상태를 정확히 아는데는 push가 좋을 수 있습니다. 제 생각에는 scp를 이용한 distribution method 자체의 문제가 아니라, 주변 tooling의 문제가 더 있지 않나 합니다. 그런데 push를 하려면 네트웍에 노출된다는 단점도 있죠. pull이라면 firewall/proxy를 통할 수 있는데 말이죠. 또한 같은 기능을 제공하는 노드들의 클러스터를 관리하는 것과, 한대 한대 각각의 상태가 중요한 경우도 관리 방법이 달라집니다.

      상황과 스케일에 따라 솔루션이 많이 달라질텐데, 좀 더 문제점과 목표에 대한 고민을 해보셔햐 할겁니다.

    • DevOps 73.***.131.168

      먼저 댓글 주신 분들, 모두 감사드립니다.

      요즘 한국 사정은 모르겠지만, 예전에는 개발자가 배포까지 담당했었는데,
      미국은 이 역할을 따로 떼어서 DevOps 라는 포지션을 만든 것 같고, 세상이 많이 변했네요. ㅎㅎ

      회사에서 현재 프로젝트 관리툴로 Jira 를 사용하고 있는데, 이슈 관리, 품질 관리, 정도로 사용하고,
      배포 관리용으로 사용하지 않고 있습니다.


      https://www.forbes.com/advisor/business/software/azure-devops-vs-jira/

      구글링을 해보면, Jira vs Azure DevOps 비교한 글들이 많이 보이는데, 이게 비교 대상인지 헷갈리네요.
      Jira 는 배포 관리툴이 없는것 같고, Azure DevOps 는 배포 관리에 특화되어 있는 환경으로 보이구요.

      저희 회사가 Jira 를 잘못 사용하고 있는걸까요?

      Bottom Line
      Both Azure DevOps and Jira are popular and useful software development tools, though your best option will largely depend on how you plan to use the tool. If you are looking for something to help you manage the entire life cycle of a software application development, from ideation to deployment, Azure DevOps will probably be your best option. If, on the other hand, you want a project development tool to be used for software development, as well as other projects, Jira can better meet your needs.

      • sil 174.***.2.154

        Jira는 프로젝트 관리 툴 – Scrum 진행/일정관리등에 쓰이는 툴입니다. Azure툴로 보자면 Azure board랑 비슷할 것 같습니다.

        Azure DevOps는 Jenkins, GitlabCI, CircleCI 같은 프로젝트를 배포하는 CI/CD용 툴과 비교하셔야 할듯 합니다.
        (Jira는 제대로 쓰고 계십니다. 🙂 )