3.1 코드에 변경 사항 반영하기
앞에서 말했듯이, 소프트웨어 개발은 코드에 작은 변경 사항을 추가하는 것으로 요약됩니다. 이 과정은 수십 년 동안 수백만 명의 프로그래머들이 참여하면서 철저하게 디버깅되고, 표준화되고, 가능한 모든 방법으로 공식화되었습니다.
코드를 저장하기 위해 특별한 프로그램이 있습니다 - Git. Git은 분산 버전 관리 시스템입니다. 이것은 단순히 코드를 저장하는 것이 아니라, 코드의 모든 변화를 추적하고 프로그래머들이 서로 방해받지 않고 프로젝트에 협력할 수 있게 합니다.
Git을 사용하면 개발자들은 프로젝트의 다른 버전(브랜치)을 만들 수 있고, 변경 사항의 전체 기록을 보관하며, 과거의 어느 시점으로든 돌아갈 수 있습니다. 이것은 코드에 대한 타임 머신과 같은 것입니다! Git은 변경 사항을 병합하고 충돌을 해결하는 데 도움을 주어서 현대 개발에서 팀워크에 필수적인 도구가 되었습니다.
3.2 프로젝트 빌드하기
프로젝트를 테스트하거나 서버로 업로드하기 전에 빌드해야 합니다.
프로젝트 빌드는 소스 코드를 실행 가능한 프로그램 또는 기타 실행 가능한 형식으로 컴파일하는 과정입니다. 종종 테스트 및 배포를 포함합니다. 이것은 소프트웨어 개발의 중요한 측면으로, 프로그램이 사용 준비가 되었음을 보장합니다.
빌드는 단순한 컴파일링이 아니지만, 컴파일링이 빌드 과정의 일부일 때가 많습니다. 빌드가 완료되면, 여러 서버에 업로드해야 하는 수십 또는 심지어 수백 개의 파일을 가지고 있을 수 있습니다.
빌드 도구에는 저수준의 것들이 있을 수 있습니다, 예를 들어:
Maven과 Gradle은 프로젝트의 의존성 관리와 빌드를 위해 Java 프로젝트에서 널리 사용됩니다.
Apache Ant는 Java 프로젝트 빌드를 위한 또 다른 도구로, 빌드 스크립트를 작성하는 데 유연성을 제공합니다.
MSBuild는 Microsoft Visual Studio를 사용하여 생성된 프로젝트를 빌드하는 데 사용됩니다.
Make는 Makefile을 사용하여 빌드 규칙을 정의하는 고전적인 빌드 도구로, 특히 C와 C++ 프로젝트에서 인기가 많습니다.
Webpack은 JavaScript 애플리케이션의 빌드에 자주 사용되어 의존성과 모듈을 관리합니다.
Gulp와 Grunt는 웹 애플리케이션 개발에서 파일 미니피케이션 및 SCSS의 CSS로의 컴파일과 같은 반복적인 작업을 자동화하는 데 도움을 주는 도구입니다.
고수준의 빌드 도구도 있습니다. 이것들은 아래에서 다루겠습니다.
3.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 또는 "지속적 통합"과 같은 것이 대화에서 언급되면 그것이 무엇이든 이해할 수 있는 것이 중요합니다.
3.4 프로젝트를 서버로 전송하기
프로젝트를 작성하는 것만으로는 충분하지 않으며, 서버에 있어야 합니다. 사실 프로젝트를 서버에 배포하는 것은 웹 애플리케이션을 인터넷을 통해 사용자에게 제공할 수 있도록 서버에 위치시키고 활성화시키는 것입니다.
이 과정은 프로젝트 파일을 서버로 전송하고, 서버 환경, 데이터베이스, 의존성을 설정하며, 네트워크 설정 및 보안을 구성하는 것을 포함합니다.
코드를 서버에 어떻게 올릴까요? 누가 대신 올려줄까요? 아니면 SSH로 원격 서버에 연결하여 몇 개의 파일을 올리고 모든 것을 설정할까요? 이제 더 이상 그렇게 하지 않습니다. 이제 Docker가 있습니다.
Docker는 컨테이너를 사용하여 애플리케이션을 개발, 배포 및 실행하기 위한 플랫폼입니다. Docker는 모든 의존성과 환경을 함께 패키지화하여 애플리케이션을 쉽게 만들고 배포하고 실행할 수 있게 합니다. 개발, 테스트, 프로덕션의 모든 단계에서 환경의 일관성을 보장합니다.
Docker는 프로젝트를 Docker 컨테이너에 패키지화할 수 있게 합니다. 이것은 일종의 가상 머신과 유사합니다.
물론 Docker를 "가상 머신"이라고 부르면 어떤 포럼에서든 비난을 받을 수 있지만, Docker 컨테이너를 일종의 가상 머신으로 생각할 수 있습니다. 단지 훨씬 더 경량화된 것입니다.
본질적으로 Docker 컨테이너는 가상 ‘가상 머신’입니다. 가상 머신은 운영 체제의 전체 복사본, OS 커널, 가상 하드웨어를 포함하지만, Docker 컨테이너는 호스트의 커널을 공유하며 더 가볍고 빠를 수 있습니다.
Docker를 사용한 프로젝트 배포는 과정을 크게 단순화하여 빠르고 신뢰할 수 있게 만듭니다. 프로젝트는 Docker 컨테이너에 패키지화되어 Docker를 지원하는 어떤 시스템에서도 쉽게 이동하고 실행할 수 있습니다.
이는 서버 환경의 차이로 인한 문제를 없애고, 부하에 따라 컨테이너를 추가하거나 제거함으로써 애플리케이션을 쉽게 확장할 수 있게 합니다. 모두가 Docker로 전환했으며, 매우 편리하고 단순합니다.
GO TO FULL VERSION