12.1 코드에 변경 사항 반영하기
위에서 이야기한 것처럼, 현대 개발은 코드에 작은 변경 사항을 반영하는 것입니다. 수백만 명의 개발자들이 수십 년 동안 이 작업을 하고 있어서, 이 프로세스는 모든 가능한 방법으로 조정되고 표준화되었습니다.
먼저, 코드를 저장하기 위한 특별한 프로그램이 있습니다 - Git. Git은 분산 버전 관리 시스템으로, 코드 변경 사항을 추적하고 공동 프로젝트에서 개발자 간의 작업을 조율하는 데 사용됩니다.
Git은 개발자들이 프로젝트에서 브랜치를 만들고, 이렇게 생성된 브랜치에서 완전한 변경 기록을 보존하며 파일의 어떤 상태로든 되돌아갈 수 있는 기능을 제공합니다. 이는 변경 사항 병합과 충돌 해결을 효과적으로 지원하여, 현대 소프트웨어 개발에서 코드 공동 작업의 주요 도구가 됩니다.
둘째로, 코드에 변경 사항을 반영하는 프로세스도 표준화되어 있습니다. 일반적으로 새로운 기능마다 Git에 새로운 브랜치를 만들고, 커밋 시리즈로 변경 사항을 반영합니다. 그런 다음 Pull Request를 보내 팀 리더나 팀 동료에게 코드 리뷰를 요청하고 변경 사항을 확인받습니다.
모든 것이 잘 진행된다면, 변경 사항은 dev 브랜치에 병합되고, 프로젝트의 자동 빌드와 테스트가 시작됩니다. 아주 많은 테스트들이요.
12.2 프로젝트 빌드하기
프로젝트를 테스트하거나 서버에 업로드하기 전에, 먼저 프로젝트를 빌드해야 합니다.
프로젝트 빌드는 프로젝트 소스 코드를 실행 가능한 프로그램이나 다른 실행 가능한 형식으로 컴파일하는 프로세스입니다. 종종 테스트와 배포가 포함되며, 이는 소프트웨어 개발의 중요한 측면으로 프로그램 사용 준비를 보장합니다.
빌드는 컴파일이 아니지만, 컴파일은 빌드 프로세스의 일부일 수 있습니다. 빌드가 완료되면 종종 여러 대의 서버에 필요한 수십 또는 수백 개의 파일들이 있을 수 있습니다.
빌드 도구는 저수준일 수 있습니다:
Maven 및 Gradle — Java 프로젝트에서 의존성 관리와 프로젝트 빌드를 위해 널리 사용됩니다.
Apache Ant — Java 프로젝트 빌드를 위한 또 다른 도구로, 빌드 스크립트를 작성하는 데 큰 유연성을 제공합니다.
MSBuild — Microsoft Visual Studio를 사용하여 생성된 프로젝트를 빌드하는 데 사용됩니다.
Make — Makefile을 사용하여 빌드 규칙을 정의하는 클래식 빌드 도구로, 특히 C와 C++ 프로젝트에서 인기가 높습니다.
Webpack — JavaScript 애플리케이션 빌드에 자주 사용되며, 의존성과 모듈을 관리합니다.
Gulp 및 Grunt — 웹 애플리케이션 개발에서 자주 수행되는 작업을 자동화하는 도구로, 파일 축소 및 SCSS를 CSS로 컴파일하는 작업 등을 포함합니다.
빌드 도구는 고수준일 수도 있습니다. 이들에 대한 내용은 아래에서 다룹니다.
12.3 CI/CD
CI/CD (Continuous Integration/Continuous Delivery)는 모든 개발 브랜치에서 주요 브랜치로의 지속적인 병합과 이러한 변경 사항의 자동 테스트 및 배포를 의미하는 방법론입니다. 이는 오류를 빠르게 식별하고 수정할 수 있게 하여 개발의 효율성과 속도를 높입니다.
가장 널리 사용되고 약간 구식이기는 하지만 여전히 많이 사용되는 CI/CD 시스템은 Jenkins입니다. 작은 회사에서 일한다면 80%의 확률로 이 시스템을 사용할 것입니다.
Jenkins — 지속적 통합 및 배포 (CI/CD)에서 사용되는 인기 있는 자동화 시스템입니다. Jenkins는 소프트웨어 개발의 다양한 단계를 자동화하여 빌드, 테스트 및 배포를 포함하여 코드 품질 향상과 개발 프로세스를 가속화합니다.
큰 회사에 합류하면 다음 5가지 옵션 중 몇 가지를 선택할 수도 있습니다:
TeamCity — JetBrains에서 제공하는 강력한 상업적 시스템으로, 다양한 개발 및 테스트 환경과의 깊은 통합을 제공합니다.
GitLab CI — GitLab의 일부분으로, YAML 파일을 통한 지속적 통합 및 배포 기능을 제공합니다.
CircleCI — 다양한 프로젝트의 테스트 및 배포 자동화를 지원하는 클라우드 기반 CI/CD 서비스입니다.
Travis CI — 가장 초기의 클라우드 기반 CI 서비스 중 하나로, 많은 오픈 소스 프로젝트에서 사용되며 GitHub와 잘 통합됩니다.
Bamboo — Atlassian에서 제공하며 Jira 및 Bitbucket과 같은 이 회사의 다른 도구와 긴밀히 통합됩니다.
이러한 도구들을 알고 있어야 하거나 사용할 줄 알아야 할 필요는 없습니다. 회사에는 보통 DevOps 전문가가 있어 이러한 빌드 프로세스를 설정합니다. 여러분은 단지 이 도구들이 존재한다는 것을 알고, 대화에서 Jenkins, CI/CD, 또는 '컨티뉴어스 인테그레이션'이 언급될 때 무엇에 대한 이야기인지 이해하면 됩니다.
12.4 프로젝트를 서버로 전달하기
프로젝트를 작성하는 것만으로는 부족하며, 서버에 배포해야 합니다. 일반적으로 서버로 프로젝트를 배포하는 것은 웹 애플리케이션을 서버에 배치 및 활성화하여 인터넷을 통해 사용자에게 접근 가능하게 하는 프로세스입니다.
이는 프로젝트 파일을 서버로 전송하고, 서버 환경을 설정하고, 데이터베이스 및 의존성을 구성하며, 네트워크 설정과 보안을 조정하는 것을 포함합니다.
그럼, 여러분의 코드가 서버로 어떻게 전달되나요? 누군가가 그것을 업로드해줄까요? 아니면 SSH를 통해 원격 서버에 연결하여 몇 개의 파일을 전송하고 모든 것을 설정해야 할까요? 걱정하지 마세요. 이제는 더 이상 그렇게 하지 않습니다. 이제 Docker가 있습니다.
Docker — 애플리케이션을 컨테이너화하여 개발, 전달 및 실행하는 플랫폼입니다. Docker는 컨테이너를 사용하여 애플리케이션을 생성, 배포 및 실행하는 과정을 쉽게 하며, 애플리케이션과 모든 환경 및 의존성을 하나의 컴팩트한 객체로 패키징하여 개발, 테스트 및 프로덕션의 모든 단계에서 환경의 일관성을 보장합니다.
Docker는 여러분의 프로젝트나 프로젝트들을 Docker 컨테이너로 패키징할 수 있게 해줍니다. 이는 가상 머신의 일종이지만 매우 가볍습니다.
Docker를 가상 머신이라 부르면 어떤 포럼에서는 비난을 받을지도 모르지만, 가상 머신이 무엇인지 알고 있다면 Docker 컨테이너를 가상 머신으로 생각해도 괜찮습니다. 매우 가벼운 가상 머신이죠.
요컨대, Docker 컨테이너는 가상의 '가상 머신'입니다. 가상 머신은 전체 운영 체제의 복사본, 운영 체제의 커널, 그리고 가상 하드웨어를 포함하지만, Docker 컨테이너는 호스트의 커널을 공유하고 보다 가볍고 빠를 수 있습니다.
게다가, Docker를 사용한 프로젝트 배포는 애플리케이션 배포 프로세스를 크게 단순화하여 빠르고 신뢰성을 제공합니다. 프로젝트는 Docker 컨테이너에 패키징되어 쉽게 이동 및 실행 가능합니다. Docker를 지원하는 시스템에서 언제든지. 이는 서버 환경의 차이점과 관련된 문제를 해결하고, 부하에 따라 컨테이너를 추가 또는 제거하여 애플리케이션을 쉽게 확장할 수 있게 합니다. 모두가 Docker로 전환했습니다 — 정말 편리하고 간단합니다.
GO TO FULL VERSION