요즘 애자일(Agile), 애자일 방법론 , Devops 라고해서 많이 뜬다.
초기 소프트웨어 개발방법은 '계획 -> 설계 -> 빌드 -> 테스트 -> 배포 -> 서포트' 라는 계획 중심에 가까웠다.
하지만 지금은 너무나도 시대가 빠르게 변화하고 있고 유동적이어서 사용자가 많은 시간을 기다려 주지 않는다.
그런 불확실한 미래에 발빠르게 대응하기 위해 전략들이 나오게 되었는데 그중 하나가 애자일이다.
애자일은 사용자 요구에 맞춰 빠른 피드백으로 테스트하고 개발하고 지속적으로 반영하는 방식이다.
사용자는 최소 기능 제품을 일찍 볼 수 있고, 회사는 사용자의 피드백을 통해 다음 제품을 더 훌륭하게 만들 수 있다.
즉, 소통, 협업, 통합 및 자동화를 강조하는 소프트웨어 개발론이고 개발과 운영이 상호의존적으로 대응해야한다는 의미이다.
애자일 소프트웨어 개발에서는 작은 변경을 자주 출시하기 때문에 개발 담당자와 운영 담당자의 협업이 긴밀해야 하며, 이러한 개발 방법의 보급과 함께 데브옵스 (Development와 Operations의 합성어) 에 대한 개념도 널리 보편화되었다.
공통점은
1. 소프트웨어 개발, 서비스 개발에 필요한 방법,
2. 빠르게 변화하는 환경에 유연하게 대응하는 것을 목표
3. 고객과 개발자/관리자 간의 주기적인 개발 결과물, 산출물 결과희의와 승인을 통해 2~3주마다 회의진행 (최대 1달을 넘기지 않는걸 목표로 한다-프로젝트마다 차이는 있겠지만?)
이러한 애자일 방식과 Devops를 지원하는 소프트웨어 개발 도구들이 출시되고 있다.
대표적으로 아틀라시안(Atlassian)과 액소소프트(Axosoft) 등 이 있다.
1. Jira 란?
[https://www.atlassian.comhttps://www.atlassian.com/software/jira]
지라(JIRA)는 아틀라시안이 개발한 사유 이슈 추적 제품이다.
버그 추적, 이슈 추적, 프로젝트 관리 기능을 제공하는 소프트웨어이다.
지라(JIRA)라는 이름은 고지라라는 일본식 이름에서 따왔다. 2002년부터 지금까지 개발되고 있다.
영어, 프랑스어, 독일어, 일본어, 스페인어를 포함한 여러 번역을 포함하고 있다. 지라는 경쟁 제품인 버그질라로부터의 마이그레이션을 도와주는 도구를 포함하고 있다. [출처:위키백과]
2. Bitbucket 이란?
[https://bitbucket.org/product]
빗버킷(Bitbucket)은 아틀라시안 소유의 웹 기반 버전 관리 저장소 호스팅 서비스로서, 머큐리얼(2020년 6월 1일 이후) 또는 Git(2011년 10월 이후) 버전 관리 시스템을 사용하는 소스 코드 및 개발 프로젝트를 대상으로 한다.
빗버킷은 상용 플랜과 무료 계정을 동시에 제공한다. 2010년 9월 기준으로 무료 계정의 경우 무제한 수의 개인 저장소(무료 계정의 경우 최대 5명의 사용자 보유 가능)를 제공한다.
빗버킷은 지라, 힙챗, 컨플루언스, 밤부 등의 기타 아틀라시안 소프트웨어와 연동된다.
빗버킷은 3개의 디플로이먼트 모델이 있다:Cloud, Bitbucket Server, Data Center. [출처:위키백과]
1. 코드 협업 : 코드 리뷰로 고품질 소프트웨어 빌드
풀 리퀘스트를 사용해서 더 효율적으로 코드 리뷰를 승인
지정된 승인자와 병합 체크리스트를 만들고 인라인 댓글을 사용해서 소스 코드에 바로 토론 내용을 포함할 수 있다.
2. 지속적 배포 (CONTINUOUS DELIVERY) : 기본 제공되는 지속적 배포로 여러 번 배포 - 코드 구성과 빠른 피드백 루프의 혜택
배포 기능이 포함된 Bitbucket Pipelines로 통합된 CI/CD를 빌드, 테스트, 배포할 수 있다.
3. 보안 : 워크플로우 보안 유지
IP 인증 허용 목록 및 필수 2단계 인증을 통해 클라우드에서 안전하게 유지된다.
특정 사용자에 대한 액세스를 제한하고 브랜치 권한으로 작업을 제어하고 품질 코드에 대한 병합 검사를 수행할 수 있다.
3. Jenkins 란?
젠킨스(Jenkins)는 소프트웨어 개발 시 지속적 통합(continuous integration) 서비스를 제공하는 툴이다.
※ 지속적 통합이란?
소프트웨어 공학에서, 지속적 통합(continuous integration, CI)은 지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행하는 것이다.
- 작은 단위의 작업, 빈번한 적용. 지속적인 통합은 모든 개발을 완료한 뒤에 퀄리티 컨트롤을 적용하는 고전적인 방법을 대체하는 방법으로서 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는데 초점이 맞추어져 있다.
다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유 영역에 있는 Git등의 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 해 준다. MIT 라이선스를 따른다.
젠킨스는 오라클과의 분쟁 이후 허드슨으로부터 분기되었다. [출처:위키백과]
다른 일상적인 개발 작업을 자동화할 뿐 아니라 파이프라인(Pipeline)을 사용해 거의 모든 언어의 조합과 소스코드 리포지토리에 대한 지속적인 통합과 지속적인 전달 환경을 구축하기 위한 간단한 방법을 제공한다.
젠킨스를 사용해야하는 이유
개발 중인 프로젝트에서 커밋은 빈번하게 일어나기 때문에 커밋 횟수만큼 빌드를 실행하는 것이 아니라 작업이 큐잉되어 자신이 실행될 차례를 기다리게 된다. 코드의 변경과 함께 이루어지는 이 같은 자동화된 빌드와 테스트 작업들은 다음과 같은 이점들을 가져다준다.
- 결합 테스트 환경에 대한 배포 작업 실시
- 정적 코드 분석에 의한 코딩 규약 준수 여부 체크
- 자동화 테스트 수행
- 프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출
- 프로파일링 툴을 이용한 소스 변경에 따른 성능 변화 감시
각종 배치 작업의 간략화
: 프로젝트 기간 중에 개발자들은 DB 셋업, 환경설정, Deploy 작업과 같은 단순 작업에 시간과 노력을 들이는 경우가 빈번하다.
데이터베이스의 구축, 애플리케이션 서버로의 Deploy, 라이브러리 릴리즈와 같이 이전에 CLI로 실행되던 작업들이 젠킨스 덕분에 웹 인터페이스로 쉽게 가능해졌다.
Build 자동화의 확립
: 빌드 툴의 경우 Java는 maven과 gradle이 자리 잡고 있으며, 이미 빌드 관리 툴을 이용해 프로젝트를 진행하고 있다면 젠킨스(Jenkins)를 사용하지 않을 이유가 없다. 젠킨스와 연동하여 빌드 자동화를 통해 프로젝트 진행의 효율성을 높일 수 있다.
빌드 파이프라인 구성
: 두 개 이상의 모듈로 구성되는 레이어드 아키텍처가 적용된 프로젝트에는 그에 따른 빌드 파이프라인 구성이 필요하다. 예를 들면,
도메인 ▶ 서비스 ▶ UI 와 같이 각 레이어의 참조 관계에 따라 순차적으로 빌드를 진행해야 한다. 젠킨스 (Jenkins)에서는 이러한 빌드 파이프라인의 구성을 간단히 할 수 있으며, 스크립트를 통해 매우 복잡한 제어도 가능하다.
자동화 테스트**
: 자동화 테스트는 젠킨스(Jenkins)를 사용해야 하는 가장 큰 이유 중 하나이며, 사실상 자동화 테스트가 포함되지 않은 빌드는 CI 자체가 불가능하다고 봐도 무방하다. 젠킨스는 Subversion이나 Git과 같은 버전 관리 시스템과 연동하여 코드 변경을 감지하고 자동화 테스트를 수행하기 때문에 만약 개인이 미처 실시하지 못한 테스트가 있다 하여도 든든한 안전망이 되어준다.
코드 표준 준수 여부 검사
: 자동화 테스트와 마찬가지로 개인이 미처 실시하지 못한 코드 표준 준수 여부의 검사나 정적 분석을 통한 코드 품질 검사를 빌드 내부에서 수행함으로써 기술적 부터의 감소에도 크게 기여한다.
젠킨스(Jenkins) 서버는 현재 진행 중인 프로젝트가 정상적으로 빌드가 되고 있는지를 정기적으로 체크하여 팀원들에게
빠른 결과를 알려줌으로써 문제 발생 시 각각 팀 멤버들이 큰 문제없이 각자 맡은 부분에 차질 없이 작업할 수 있도록 도와준다.
또한 프로젝트 빌드 시 자동으로 유닛 테스트와 통합 테스트가 커버하고 있는지 및 어떤 부분에 문제가 있을지 등의 정보도
SonarQube와 같이 연동 시 모니터링할 수 있도록 도와준다.
'Tool' 카테고리의 다른 글
| VSC 자주 쓰는 단축키 정리 (0) | 2021.11.12 |
|---|