DevOps는 development와 operations가 합쳐진 단어이며, 소프트웨어 개발과 배포 프로세스를 자동화하고 통합하는 개발방법론, 철학이다. 팀 지원, 팀 간 커뮤니케이션 및 공동 작업, 기술 자동화를 강조한다.
DevOps는 소프트웨어 제공 프로세스를 효율적으로 수행하는 것을 목표로 한다. 이를 위해 워크플로를 자동화하고 신속하게 피드백하여 프로젝트를 더 잘 제어할 수 있도록 하는 여러 방법을 사용한다.
DevOps 문화 철학
DevOps에서는 개발과 운영이라는 두 팀간의 장벽을 없애 개발자의 생산성과 운영의 안정성을 모두 최적화한다. 두 팀은 자주 소통하고, 효율성을 높이고, 고객에게 제공하는 서비스의 품질을 향상하기 위해 최선을 다한다. 최종 고객의 요구와 자신이 어떻게 이러한 요구를 해결하는 데 공헌할 수 있는지 생각함으로써 일반적으로 명시된 역할 또는 직책의 범위를 넘어 서비스에 대한 완전한 주인의식을 갖는다.
DevOps 모델을 사용하는 조직은 어떻게 구성되어 있든, 전체 개발 및 인프라 수명 주기를 스스로의 책임으로 간주하는 팀들로 구성돤다.
DevOps과 Agile
DevOps는 Agile과 연장선에 있다. Agile의 목표가 Lean Manufacturing에 기반하여 빠른 소비자 피드백을 가질 수 있게 해준다면, DevOps는 분리되어있던 개발자와 운영자의 역할을 합쳐버리니 더욱 빠른 개발 및 배포 사이클을 가질 수 있다.
Agile과 DevOps는 변화에 기민하게 대응하고, 시장에 신속히 제품을 릴리즈하기 위하여 짧은 배포(Release) 주기를 가진다는 점에서 동일한 지향점을 가진다.
DevOps의 장점
데브옵스는 개발과 운영을 통합하여 제품 출시 및 조직의 효율성을 끌어올리기 위한 문화이다. DevOps를 잘 적용한다면, 기존의 소프트웨어 개발 및 인프라 관리 프로세스를 사용하는 조직보다 제품을 더 빠르게 혁신하고 개선할 수 있다. DevOps는 여러 측면에서 이점을 가지고있다.
DevOps 생명주기
DevOps의 지속적인 특성때문에, DevOps를 따르는 조직은 일련의 과정을 계속해서 반복하게 된다. 이 과정의 사이클을 DevOps 생명 주기라고 부른다. DevOps 생명 주기는 개발 및 운영에 필요한 프로세스, 기능 및 도구를 나타내는 8단계로 구성된다. 각 단계에서 팀은 계속적으로 커뮤니케이션하여 의견을 조정하고, 속도 및 품질을 유지 관리한다. (Collaboraion And Communication)
(DevOps 생명주기. 왼쪽은 개발, 오른쪽은 운영에 관련된 프로세스이다.)
Plan
계획 단계에서 DevOps 팀은 빌드하려는 애플리케이션 및 시스템의 기능과 기능을 아이디어, 정의하고 설명한다. 관계자와 고객으로부터 수집된 요구사항과 피드백을 정리하여 로드맵을 작성하고, 전체적인 애플리케이션을 여러 세부적인 단계로 나누어 계획한다. Plan 단계에서는 아래와 같은 활동들을 할 수 있다.
- 백로그를 만든다.
- 버그를 추적한다.
- 스크럼을 사용하여 Agile 소프트웨어 개발을 관리한다.
- Kanban 보드를 사용한다.
- 대시보드를 사용하여 진행률을 시각화한다.
사용 Tool : Jira, Git
Code
Code는 개발 환경을 준비하고 코드를 작성하는 단계이다. 이 단계에서 코드를 작성할 때는 일관된 코드 스타일을 적용하며 일반적인 보안 결함 및 코드 안티 패턴을 방지한다.
이는 코드베이스에 어느 정도 일관성을 제공하여 협업을 지원하면서 개발자에게 좋은 코딩 방법을 가르치는 데 도움이 된다. 또한 이러한 도구는 나중에 파이프라인에서 테스트에 실패할 수 있는 문제를 해결하여 빌드 실패를 줄이는 데 도움된다.
사용 Tool : GitHub, GitLab, Bitbucket, Stash
Build
Build는 DevOps가 실제로 시작되는 단계이다. 버전 제어 툴을 사용하여 코드를 공동으로 작업하고, 그 코드를 합쳐 빌드한다. 새로운 코드 기능을 기존 소스 코드와 지속적으로 통합하는 CI(지속적 통합)와 같은 의미를 가진다.
사용 Tool : Docker, Ansible, Puppet, Chef, Gradle, Maven, JFrog Artifactory
Test
Test는 코드에 버그 및 오류가 포함되어있는지 확인하는 단계다. 여기서 품질 분석(QA)은 개발된 소프트웨어의 사용성을 확인하는 중요한 역할을 한다. QA 프로세스의 성공적인 완료는 소프트웨어가 클라이언트의 사양을 충족하는지 여부를 결정하는 데 중요하다.
Test 단계에서는 JUnit, Selenium 및 TestNG와 같은 자동화 도구를 사용할 수 있다. 이렇게 하면 개발된 소프트웨어에 결함이 없는지 빠르게 확인하는 것이 가능한다.
사용 Tool : JUnit, Codeception, Selenium, Vagrant, TestNG, BlazeMeter
Release
Release는 빌드된 코드가 프로덕션 환경에 배포할 준비가 되었다고 말하는 시점으로, DevOps 파이프라인의 이정표이다. 이 단계에서 각 코드 변경은 일련의 수동 및 자동화 테스트를 통과했으며 큰 버그가 일어날 가능성이 낮다고 확신할 수 있다.
조직의 DevOps 성숙도에 따라 파이프라인의 이 단계에 도달하는 모든 빌드를 자동으로 배포하도록 선택할 수 있다. 조직이 여러 기능을 빠르게 배포하기 위해선 이 단계에서 CI/CD를 적용한다.
Deploy
Deploy는 코드가 실제로 프로덕션에 배포되는 단계이다. 릴리스 프로세스를 자동화하여 중단 기간 없이 릴리스를 안정적으로 만들 수 있는 도구나 프로세스를 사용할 수 있다.
테스트 환경을 구축한 것과 동일한 코드로서의 인프라를 프로덕션 환경을 구축하도록 구성할 수 있다. 테스트 환경이 성공적으로 구축되었다는 것을 이미 알고 있으므로 프로덕션 릴리스가 차질 없이 진행될 것이라고 안심할 수 있다.
사용 Tool : Puppet, Chef, Ansible, Jenkins, Kubernetes, Docker, Jira
Operate
새 릴리스가 출시되어 고객이 프로덕트를 사용할 수 있는 단계이다. 이 단계에서 Devops 관리자는 해당 서비스를 운영하고 관리해야한다.
조직은 서비스에 대한 고객의 피드백을 받고, 이 피드백을 수집·분류하여 제품의 향후 개발을 구체화할 수 있도록 여러 도구를 사용하기도 한다.
사용 Tool : Anabilities, Puppet, PowerShell, Chef, Salt, Otter
Monitor
Monitor는 시스템이 잘 돌아가고 있는지 감시하는 단계이다.
만약 서비스의 장애가 비즈니스에 영향을 준다는 생각이 든다면 애플리케이션 모니터링을 통해 MTTR(mean time to recovery, 복구에 들어가는 시간)을 줄여나가야한다. 애플리케이션 모니터링 서비스를 사용하지 않는 상황에서는 장애 발생 확인이 실시간일 확률이 낮다.
애플리케이션(및 환경)의 추세와 전반적인 상태를 이해하려면 연중무휴 24시간 데이터를 리스닝하고 기록하는 소프트웨어가 필요하다. Mornitor 단계에서는 장애 시간의 동시 사용자 수, 초당 트랜잭션의 개수, 평균 응답시간, CPU 부하율, 사용된 커넥션의 개수, 쿼리의 응답시간 등의 정보를 항상 확인하여 지속적인 가시성은 성공적인 DevOps 팀을 위한 핵심 기능이다.
사용 Tool : Anabilities, Puppet, PowerShell, Chef, Salt, Otter
