React는 사용자 인터페이스를 구축하기 위해 널리 사용되는 JavaScript 라이브러리입니다. 이 튜토리얼에서는 새로운 리액트 어플리케이션을 만들고 GitLab에서 CI 프로세스의 일부로 유닛 테스트를 실행하고 테스트 결과와 코드를 파이프라인에 출력하는 방법을 배울 수 있습니다.

오늘날 모든 회사는 소프트웨어 회사이므로 혁신 및 제공 수준이 수익 창출에 직접적인 영향을 미칩니다. 성공하기 위해 기업은 놀라운 디지털 경험을 제공하고, 최신 기술을 따라잡고, 고객이 요구하는 속도로 가치를 제공하고, 중단이나 보안 위반에 대해 무관용으로 모든 작업을 수행해야 합니다. 여기서 Value Stream Management(VSM)이 시작됩니다.

지난 MergeRequest로 개발 협업하기를 끝으로 디자이너, 개발자, PM이 서로 커뮤니케이션하고 협업하는 과정을 배워봤습니다.

하지만 구체적으로 뭐가 좋은지 아직 감이 안 잡히는 분들도 계실 겁니다.
그래서 역할별로 MR(Merge Request)의 장점을 총정리하는 시간을 가져 보겠습니다.

클라우드 시대가 되면서 인프라 엔지니어는 서버실에서 벗어나게 되었습니다. AWS 콘솔에서 클릭 몇 번으로 서버를 배포하고, 명령어 한 줄로 다양한 인프라를 구축할 수 있게 되었습니다. 더 나아가 인프라를 더 빠르고, 안전하게 관리하는 방법이 등장합니다.

지난 MergeRequest 만들기 포스트에서는 PM(Project Manager)이 이슈를 생성하고 디자이너와 협업하며 MR를 생성하는 부분까지 진행하였습니다.

이번엔 MR(MergeRequest)로 개발자와 협업하는 방법에 대해 자세히 알아보겠습니다.

애플리케이션을 Docker 이미지로 만들고, 배포해본 경험 다들 있으신가요? 무거운 이미지를 베이스 이미지로 사용해 한 번 다운받는 데 무척 오랜 시간이 걸리거나, 민감한 데이터를 포함하게 되어 보안상 문제가 생겼던 경험도 다들 있으실 겁니다. 이번 포스팅에서는 더 가볍고, 안전한 이미지를 만들기 위해서는 어떻게 해야 하는지 한 번 알아보겠습니다.

DevOps를 적용한다고 하면, CI/CD를 포함하는 자동화를 제일 먼저 생각하게 됩니다. CI/CD를 완료성있게 구축하고 운영하는 일은 간단하지 않습니다. GitLab과 같이 단일 도구를 사용하면 조금 더 간단해질 수 있습니다. GitLab은 CI/CD 스크립트를 레파지토리에 .gitlab-ci.yml 파일로 소스 코드 관리하는 방식으로 이용됩니다. 소스 코드가 업데이트 되면, 파이프라인 결과를 확인할 수 있습니다. Merge Request 화면에서도 변경에 대한 파이프라인 결과를 확인하면서 자동화 테스트, 보안 테스트, 배포 결과를 확인할 수 있는 피드백을 주고 받을 수 있습니다. 이 과정을 단순화시키고 활용할 수 있는 방법을 DevOps 실무자들이 만들어갑니다. 인포그랩은 GitLab을 사용하는 실무자들이 CI/CD 파이프라인을 쉽게 운영관리할 수 있는 밀키트를 만들기 시작했습니다. 프로젝트마다 CI 스크립트를 복사 & 붙여넣기 하지 않고 템플릿으로 쉽게 관리할 수 있습니다.

지난 'MergeRequest 왜 사용해야 할까?'에서는 협업을 하면서 발생하는 문제점과 MR(MergeRequest)의 이점을 살펴보고 MR을 사용해야하는 이유를 알아보았습니다.

오늘은 본격적으로 MR 사용법을 배워보도록 하겠습니다.

Docker로 애플리케이션을 배포하여 서비스를 운영 중인 Linux 서버에 디스크 용량이 부족하다는 오류나 경고 메시지가 발생한 경험이 있으신가요?

프로젝트 협업 어떻게 하는게 좋을까요?

우리의 삶에서 인터넷을 떼어 놓을 수 없듯이 어떤 서비스를 하든 소프트웨어가 빠지는 곳이 없습니다. 소프트웨어의 사이즈는 거대해졌고, 기술과 사회는 빠르게 변화하고 있습니다. 그래서 보다 빠르게 개발하고 배포하는 것이 중요해졌습니다. 이를 위해 다수의 사람들이 협업하여 개발을 진행하고 있습니다. 그런데 수많은 사람들이 협업을 하는데 문제가 발생하지 않을까요? 여러 사람들과 협업을 하다보면 다양한 문제를 마주치게 됩니다.

클라우드에서 인프라를 구축을 할 때 비용 절감, 배포 속도 향상, 일관성, 안정성 및 재사용성을 고려하여 웹 콘솔로 구축하기보다는 IaC(Infrastructure as Code) 도구를 활용하여 구축하는 것이 좋습니다. 오픈소스이며 IaC 도구 중 가장 많이 사용하는 것이 Terraform입니다. Terraform 코드를 효율적이고 효과적으로 작성하기 위해서는 Terraform에서 제공되는 기능들을 적절하게 사용하는 것이 중요합니다. 그렇지 않으면 예상과 다른 결과가 발생할 수 있습니다. 이번 글에서는 Terraform에서 제공하는 각 반복문의 특징과 차이점을 알아보겠습니다.

구축형 GitLab을 설치해보셨거나 설치하실 계획이 있으신가요? 구축형 GitLab을 사용하기 위해 고려해야 하는 상황은 다양합니다. 사용하는 유저의 수, 가용성, 클라우드 네이티브 환경 여부 등 이러한 환경에 대해 전부는 아니지만, 구축에 참고할 수 있는 레퍼런스 아키텍처를 오늘 소개해 드리려 합니다.

• 일반적인 환경에서 1,000명의 사용자를 기준으로 작성된 아키텍처
• 클라우드 네이티브 환경에서 사용가능한 2,000명의 사용자를 기준으로 작성된 아키텍처

더 다양한 레퍼런스 아키텍처가 필요하신 경우에는 GitLab 공식 Docs를 참고하시기 바랍니다.

GitLab의 Compliance 관련 기능은 개발 및 배포 프로세스에서 규정 준수를 통합하도록 돕습니다. 이번에는 GitLab이 가지고 있는 Compliance 기능(이하 규정 준수)에 대해 설명합니다.

왜 GitLab 인스턴스의 보안과 규정 준수에 대해 알아야할까요?

리스크를 줄이고 비용을 절감하는 것 이외에도 고려해야 할 규정 및 준수 사항이 있습니다.

일반적으로 규제 및 감사는 기업이 규모화 됨에 따라 피할 수 없는 일이며, 관리되기까지 시간이 많이 걸리고 스트레스가 될 수 있습니다. GitLab은 조직의 규정 준수 사항을 만족하고, DevOps 툴의 운영 환경을 보다 안전하게 만들기 위한 몇가지 내장 기능을 가지고 있습니다. 우리가 매일 사용하는 기능들을 포함해서 대부분의 기능들이 무료인 프리티어로 사용할 수 있습니다.

이번 포스팅에서는 코딩 컨벤션 체크에서부터, 단위 테스트, 코드 사이닝, iOS 앱 빌드, TestFlight에 앱을 배포한 것에 이르는 일련의 과정을 자동화하는 GitLab CI/CD 파이프라인을 구성하는 방법에 대해 알아보겠습니다.

이번 포스팅은 “GitLab과 Fastlane으로 iOS 앱 빌드 및 배포 자동화하기” 시리즈의 두 번째 글로, GitLab CI/CD 파이프라인을 구성하기 전에, Fastlane으로 Lint, Test, TestFlight 배포 등 각 단계별로 Lane을 정의하는 방법에 대해 알아보겠습니다.