지난 블로그(GitLab과 GitHub, 실무에서 어떤 차이가 있을까요?)에서 GitLab과 GitHub에 대해서 비교해 봤습니다. 결론적으로는 GitHub의 Git에 대한 노하우는 무시할 수 없지만, 서비스 혹은 전체 라이프사이클에 대한 여러 가지 비용적인 요소에서 GitLab이 우수하다는 것을 확인할 수 있었습니다. 이번 블로그에서는 DevOps 측면에서 GitLab CI/CD와 GitHub Action을 좀 더 면밀하게 살펴보겠습니다.

저희 인포그랩은 3~4월에 여러 교육을 진행하면서 바쁜 두 달을 지냈는데요, 그중에서 지난 3월 11일에 CJ 올리브네트웍스에서 진행했던 GitLab CI/CD 교육에 대해서 소개하겠습니다.

엔지니어들에게 문서 작업이란 결코 때어낼 수 없는 영역입니다. 문서를 정리하는 것 뿐만 아니라 작업을 어떻게 마무리 지었는지에 대한 개인 일지를 기록하기 위해 블로그를 이용하기도 합니다. 이 포스트에서는 GitLab Pages와 Hugo로 무료 블로그를 개설하고 글을 작성하기까지 과정을 정리하였습니다.

최근에 저희 Infograb에 GitLab에 대한 기술지원과 교육에 대한 문의 요청이 많아지고 있습니다. 그중에서도 CI/CD에 대한 고객들의 관심이 점점 증가하는 것을 느끼고 있습니다. 그래서 이번에는 GitLab CI/CD이 기본으로 제공하는 기능들을 소개를 해드리도록 하겠습니다.

이번 13.10 업데이트로 GitLab에서 Jira 이슈의 세부 내용을 가져올 수 있게 되었습니다. 이전에도 Jira와의 통합(Integration) 방법이 있었는데 이전에 어떤 기능이 있었고 무엇이 추가되었는지 알아보도록 하겠습니다.

최근 Notion 측의 DNS 문제로 전세계 Notion 서버가 한동안 다운되는 심각한 문제가 발생했습니다. 많은 사용자들이 Notion에 자료를 모아두기 때문에 이러한 장애로 불안함을 느끼고, 백업을 하고자 합니다. 이번 시간에는 GitLab과 Notion의 api를 활용해 Notion Workspace를 매일 자동으로 백업하는 방법을 살펴보겠습니다.

GitLab에서 CI/CD 및 배포를 설정하려면 두 가지 옵션이 있습니다. 먼저, 기본적으로 GitLab에서 제공되는 GitLab shared runner를 사용하는 것입니다. 이 경우 한 달에 2,000분의 무료 CI 파이프라인을 사용할 수 있습니다. 다음으로는, 자신의 GitLab runner를 설정하는 것입니다. GitLab은 이미 GCP와 AWS와 잘 통합되도록 설정 할 수 있게 준비되어 있습니다. 설정 대시보드에서 간단히 Google Kubernetes 클러스터와 Amazon에 GitLab runner를 설정하고 배포 할 수 있습니다. 하지만 이럴 경우 runner를 몇 번 사용하지 않았음에도 불구하고 한 달 후에 받는 비용청구서의 금액은 상상한 것보다 많을 것입니다.

저희 인포그랩을 찾아주시는 여러분들 중 많은 분이 GitLab을 도입을 고민하고 계십니다. 깃 저장소를 도입하기 위한 선택지로 GitLab과 GitHub을 염두에 두셨을 것이고, GitLab과 GitHub의 기능 비교는 다른 여러 사이트에서 많은 콘텐츠를 통해 접하셨을 거라 생각합니다.

하지만, "이렇게 기능이 차이가 나는데 그래서 실무에서는 어떻게 다른 건데?", **"우리는 뭐를 도입해야 하는 건데?"**라는 의문들은 지우지 못하셨을 것이라 짐작됩니다. 그것은 회사마다, 업무환경마다 다를 것입니다.

이번 블로그 글에서는 실무관점에서 GitLab과 GitHub을 파헤쳐 보도록 하겠습니다.

고장나지 않는 서버는 사용자 경험과 안정적인 서비스 유지를 위해 필수 불가결한 요소입니다. 이번 시간에는 AWS에서 Terraform Cloud와 Hashicorp를 이용해 샘플 서비스의 고가용성 (HA) 서버를 구축하는 실습을 통해 HA가 왜 중요한지 알아봅니다. 또한 GitLab의 강력한 기능인 CI/CD 파이프라인을 활용해 배포 과정을 간단하게 구현하겠습니다.

Merge Request 가이드와 Merge Request로 협업하기 문서를 기반으로 쉽게 따라 할 수 있는 영상 가이드를 준비 했습니다.

Merge Request는 GitLab의 핵심 기능중 하나로 Git의 브랜치와는 가장 차별화되는 것입니다. 타겟 브랜치를 소스 브랜치로 merge하기 위한 단계로 코드 리뷰를 진행하고 완료가 된다면 승인하여 merge가 진행됩니다. 또한 CI/CD를 설정해 놓았다면 Pipeline에 성공해야 merge가 완료가 됩니다. Merge Request 이후에 배포가 가능하고 변경점을 리뷰앱을 통하여 확인 가능합니다. GitHub의 풀 리퀘스트와 유사한 기능이라고 생각하면 됩니다.

그룹 혹은 팀 프로젝트에 참여하지 않고 개인 프로젝트를 진행할 경우가 있습니다. GitLab은 개발자 친화적인 UI를 갖고 있기 때문에 대부분의 작업을 Web UI에서 할 수 있습니다. 개인 프로젝트를 GitLab의 Web UI를 이용하여 시작하는 방법을 알아 보겠습니다.

GitLab을 활용한 금융권 DevSecOps 사례 웨비나가 12월 11일 금요일 GitLab 한국 엔지니어인 유인철님과, 한화생명의 윤상배님 그리고 인포그랩의 신철호가 발표하였고, 발표 중에서 국내 사례 내용을 요약해보았습니다.

규제가 진입 장벽으로 작동해서 지켜주는 시장이라면 중요하지 않을 수 있습니다. 하지만 현재는 다른 인터넷 서비스와 금융도 경쟁 해야 합니다. 즉 고객이 원하는 기능을 탐색하고 요구사항이 기능 중심으로 만들어져서, 코드로 만들고 배포하는데 하루인 기업과 기능 배포가 가능한지부터 걱정해야 하는 기업의 경쟁력의 격차를 생각해보시죠. DevSecOps는 선택이 아닌 필수입니다. GitLab 으로 하면 쉽습니다. >
(윤상배님 발표 내용 중)

AWS(Amazon Web Services)는 2019년 기준으로 전 세계 클라우드 인프라 시장의 33%를 차지하는 업계의 리더입니다. 2020년 1월 현재, AWS는 컴퓨팅, 스토리지, 데이터베이스, 분석, 네트워킹, 모바일, 개발자 도구, 관리 도구, IoT, 보안 및 엔터프라이즈 애플리케이션을 포함하여 160개에 이르는 클라우드 기반의 제품을 전 세계에 제공하고 있습니다. 스타트업, 대기업 및 정부 기관을 포함한 수백만 고객사들이 AWS의 클라우드 서비스를 이용하여 사업을 강화해 나가고 있습니다.

벌써 한참지난 2020년 3월 CEO Sid는 블로그 글을 통해 DevOps 7가지 단계중 18가지 기능을 오픈소스화 한다고 발표 했습니다. GitLab이 무료로 제공하는 가치가 충분히 넓지만, 더 많은 범위를 오픈소스로 활용할 수 있게 되었습니다. 커뮤니티가 활성화 되고, DevOps 전체를 위한 단일 도구로서 GitLab 의 가능성을 좀더 넓이기 위한 목적으로 보입니다. GitLab을 이용해서 어플리케이션을 기획하고 개발하고 빌드하고 배포하고 보안성을 유지하는데 필요한 기능들이 점점 이전보다 좋아지고 있습니다.

우리 조직의 DevSecOps 성숙도를 체크 해보세요!

GitLab에서 만든 DevSecOps 자가진단 가이드는 DevSecOps 운영상의 성숙도를 파악하고, 개선이 필요한 부분을 찾아내는 데에 도움을 드리기 위해 제작되었습니다. DevSecOps 수행에 중요한 20가지 역량 체크리스트를 통해 자가 진단을 진행하시고, 뒤에 이어지는 정의를 참조하세요. 해당 역량이 왜 중요한지 확인하세요. 그리고 무엇을 더 고려하고 발전시켜야 할 지에 대해 저희와 같이 검토해보세요.

평가가 완료되면 각 역량 충족으로 얻는 이상적인 프로세스를 확인하실 수 있습니다. 문의하기으로 연락 주시면 인포그랩에서 맞춤형으로 성숙도 진단지를 만들어서 진단하시는 것을 도와드립니다.

맞춤형 진단은 인포그랩에서 컨설팅시 제공하는 개발팀의 성숙도 체크를 참고하세요.