DevOps 2 - 협업 도구들과 용도

DevOps 개발 프로세스

코드 - 빌드 - 테스트 - 패키지 - 릴리즈 - 모니터링 - 구성

 

1.코드-기획과 디자인이 충분히 논의를 거쳐서 나온 업무정의서를 토대로 코드를 작성하고 해당코드를 병합 및 관리

2.빌드-빌드 프로세스를 통해 소스를 컴파일하고 각각의 언어에 따라 오류가 없다면 컴파일완료

3.테스트- Junit등 테스트 도구를 사용하여 코드의 품질과 해당 동작의 이상 유무 검증

4.패키지- 어플리케이션 디플로이 직전단계인 패키지 단계로 해당 코드를 묶는다 (자바의 war파일)

5.릴리즈 - 해당 부분들이 모두 검증되면 실제 운영에 반영하는 릴리즈 프로세스를 거친다. 회사마다 차이가 있으며 

직접 파일을 옮기는 경우도 있고 , 툴을 사용하기도 한다.

6.모니터링 - 로그 파일이나 다양한 분석 도구를 활용하여 실제 소스가 잘 반영되었는지 운영서비스가 잘 운영되는지 확인

7.구성(IaC) - Infra structor를 구성하고 관리하는 단계 보안 및 장애에  대한 대비를 준비할 수 있는 단계.

 

해당 과정들을 수동으로 하거나 단계를 생략한다면 ? 

소스가 반영이 안되거나 장애에 대응할 수 없다 . 

또 테스트 과정이 없으면  오류가 있는 것을 모른채 서비스가 배포될 수 있다 .

 

이런 협업들을 활용해서 업무를 효율화 하기위해 전략들이 활성화 되었고 개발도 중요하지만 운영관리의 전략 차원에서 다양한 방식이 도입되었다 .

 

Jira

-Issue 기반의 프로젝트 관리 도구

-Issue가 생성되고 완료될 때까지 상태 변화에 대해 강력한 트래킹을 제공한다. 

-Issue를 누가 발견했느지 , 누가 해결했는지  ,현재 어떤 상태인지 파악하고 한눈에 해결 및 관리 가능

-작업 현황을 확인하고 스케줄이나 우선순위를 조절할 수 있는 장점이 있다 .

-Issue에 대한 역할과 임무를 분명히 할 수 있고 , 협업시 불필요한 커뮤니케이션 비용을 줄일 수  있다.

-Issue 해결에 대한 히스토리가 남기때문에 후에 비슷한 이슈가 발생했을 때 처리 과정을 되짚어 볼 수 있다.

-개발 단계에서 버그를 관리하거나 , 소스 혹은 이미지의 수정 내역을 남길 수있다 .

www.atlassian.com/ko/software/jira

Jira | 이슈 & 프로젝트 트래킹 소프트웨어 | Atlassian

 

 

Jira Confluence 

-www.atlassian.com/ko/software/confluence/features

Confluence - 기능 | Atlassian

 

Bitbucket

 

www.atlassian.com/ko/software/bitbucket

Bitbucket | The Git solution for professional teams

Jenkins

 

-bitbucket에 올라가 있는 소스를 가져와서 빌드툴 (maven , gradle)을 활용해 빌드할 수 있고 , 과정들을 파이프라인으로 묶어 패키지화 하여 배포할 수 있다. 

- 지속적인 통합(CI)및 배포를 위한 방법을 제공한다 .

-프로젝트의 빌드 , 테스트 실행 ,배포 등의 통합을 자동화한다 .

-WAS가 없는 Python , node.js 도 플러그인을 통해 젠킨스로 CI가 가능하다 .

 

CI/CD(Continuous Integration/Continuous Delivery)란 ?

 

 애플리케이션 개발 단계를 자동화하여 애플리 케이션을 보다 짧은 주기로 고객에게 제공하는 방법 CI/CD 의 기본개념은 지속적인 통합 , 지속적인 서비스 제공, 지속적인 배포이다 . CI/CD 는 새로운 코드 통합으로 인해 개발 및운영팀에 발생하는 문제(일명 "인티크레이션 헬")을 해결하기 위한 솔루션이다. 

 특히, CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적은 자동화와 지속적인 모니터링을 제공한다 .이러한 구축 사례를 일반적으로 "CI/CD 파이프라인" 이라 부르며 개발 및 운영팀의 애자일 방식 협력을 통해 지원된다 .

 

CI(지속적 통합)

 

  현대적인 애플리케이션 개발에서는 여러 개발자들이 동일한 애플리케이션의 각기 다른 기능을 동시에 작업할 수 있도록 하는 것을 목표로 한다 .그러나 조직인 특정한날 (머지데이(병합하는 날))을 정해 모든 분기 소스 코드를 병합하는ㄴ 경우 , 결과적으로 반복적인 수작업에 많은 시간을 소모하게 된다 .이렇게 반복적인 수작업을 하는 이유는 독립적으로 작업하는 개발자가 애플리케이션에 변경 사항을 적용할 떄 다른 개발자가 동시에 적용하는 변경 사항과 충돌할 가능성이 있기 떄문이다 .이는 팀이 하나의 클라우드 기반 통합 개발 환경(IDE) 사용에 동의하는 대신 각 개발자가 각자의 로컬 IDE를 커스터마이징 하는 경우 더욱 복합적인 문제가 될 수있다. 

 CI를 통해 개발자들은 코드 변경 사항을 공유 브랜치 또는 "트렁크"로 다시 병합하는 작업을 더욱 수월하게 자주 수행 할 수있다 .개발자가 애플리케이션에 적용한 변경 사항이 병합되면 이러한 병경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고 각기 다른 레벨의 자동화 테스트(일반적으로 단위 테스트 및통합 테스트) 실행을 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인한다 .다시말해 , 클래스와 기능에서부터 전체 애플리케이션을 구성하는 서로 다른 모듈에 이르기까지 모든 것에 대한 테스트를 수행하게 된다 .

 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 더욱 빠르게 자주 수정할 수있다. 

 

CD(지속적 제공)

 CI의 빌드 자동화, 유닛 및 통합 테스트 수행 후 , 이어지는 지속적 제공 프로세스에서는 유효한 코드를 리파지토리에 자동으로 릴리즈한다. 그러므로 효과적인 지속적 제공 프로세스를 실현하기 위해서는 개발 파이프라인에 CI가 먼저 구축되어 있어야 한다 지속적인 제공의 목표는 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 확보하는 것이며 

 지속적인 제공의 경우 , 코드 변경 사항 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계에는 테스트 자동화와 코드 릴리스 자동화가 포합된다. 이 프로세스를 완료하면 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 된다 .

 

 

참고

medium.com/bom-i/jira-b2a069ab3294   

www.redhat.com/ko/topics/devops/what-is-ci-cd (CI / CD 개념 , 방법 , 장점 , 구현 과정)