오픈 소스 SW PART.CI/CD, 이슈관리

서론

교과목 5주차 수업 내용을 정리해 보겠습니다.

 

본론

- 지속적 통합

=> 문제점

내가 하면 잘 돼, 쟤가 하면 안 돼!! > 보편적으로 동작하지 않습니다. 그 이유가 여러 명이 개발을 같이 하여 버전 차이와 에러가 여러 곳에서 발생했기 때문인데 이것을 예전에는 손수하거나, 개발자의 높은 고집 때문에 사용하지 않았습니다.

 

=> 정의

여러 개발자가 수행한 코드 변경 사항을 단일 소프트웨어 프로젝트에 지속적으로 통합하는 활동(여러 명이 개발을 하면 계속해서 각자 만든 코드를 모아야 하는데 이를 자동화하여 지속적으로 계속 모으겠다! 즉, 지속적으로 코드를 모으는 것을 자동화하겠다는 것입니다.)

 

- 지속적 배포

=> 정의

지속적으로 자동으로 모은 것을 지속적으로 배포하는 것

 

 

=> 요약

모으고 제품으로 배포를 하는 건데 사람의 손으로 하면 실수가 일어나니 툴로 자동으로 100% 무결하게 해보자!

 

=> 출근 예시

출근을 하면 git에 pull > 젠킨스를 체크 > 하고 할 일을 하다가 퇴근 전에 push

 

-> 해석

젠킨스가 지속적 통합 툴입니다. 오후 11시부터 개발자가 각자 본인들이 코딩한 내용을 build 합니다. 그러면 젠킨스가 모읍니다. (이것이 통합!) > 모은 내용을 가지고 레포트를 씁니다. 그리고 에러를 분석합니다. > 그리고 개발자에게 에러를 알려줍니다. >  11시에 build 하고 집 가기 전에 레포트 결과를 받는데 만약 에러가 있으면 절대로 퇴근 못하고 마무리해야 합니다.

 

-> 예전에는 어떻게 했을까요?

형상관리 담당자가 손수 usb를 들고 사무실을 돌아서 개발자 각각에게 파일을 받습니다. > 받은 파일을 가지고 자신의 책상에 앉아서 손수 통합을 합니다. >  통합해서 검사하는데 만약 에러가 있으면 에러를 전부다 엑셀에 적습니다. 다음날 개발자에게 에러를 알려주고 오전되어서야 퇴근합니다.

-> 개발자는 반드시 테스트라는 것을 해야 합니다. 툴을 안 쓰면 폭포수 프로세스에 따라 테스트 날에 담당자가 모두 모여 며칠 밤샘을 해야 합니다.

-> 툴을 쓰면 테스트 전에 미리미리 에러가 있는 이유를 알 수 있기 때문에 지속적으로 통합을 하는 것이고 정식으로 테스트하는 날도 빨리 끝나서 집에 빨리 갈 수 있습니다. 평소에 테스트 같은 이슈 탐지를  계속 지속적으로 하는 것!

 

=> 특징

1. 툴로 하니 에러도 없고 build와 탐지도 자동으로 됩니다. 

2. 테스트도 빠르게 하여 지속적으로 배포도 가능합니다.

3. 배포와 빌드에 도커 컨테이너를 사용합니다.

 

- 이슈관리

이슈란?

단순하게는 버그, 현재는 점점 커져서 갈등, 협업, 의사소통 관리까지의 프로젝트 전체 관리가 됩니다.
-> 프로젝트 진행에 차질을 유발하는 갈등 요인입니다.(버그, 인간관계, 의사소통 다 포함)

 

필요성

개발자끼리만 있으면 깃허브로 이슈관리하면 되는데 실제 프로젝트는 디자인, 고객지원 등등의 개발 외 팀도(디자이너, 기획 등) 회사에 있으므로 이슈를 텍스트로 보여주게 하는 것이 이슈관리의 목적입니다.

-> 이슈란 이미 발생한 갈등 요인이고 발생한 이슈를 목록화하고 해결해야 합니다.(깃허브의 issue 리스트)

재현 불가능한 이슈

그냥 기록만 남기고 지웁니다, 이때 기록은 이러이러한 이유로 발생했을 거라고 추정된다고 기록합니다. > 재현이 불가능한 이슈가 계속 생기면 패턴이 생기고 기록을 봐서 "아 이때, 발생했던 이슈였구나" 하고 패턴을 익힙니다.

 

이슈 관리 툴

=> 이슈 관리란?

1. 발생한 이슈를 목록화

2. 지속적으로 발생한 이슈에 대한 진행 상황 확인

3. 개별 이슈에 대한 우선순위, 담당자 배정

 

4. 종결 이슈에 대한 목록화

-> 해결책 제시는 불가 > 하지만 이슈 추적이 가능!