소프트웨어 QA를 처음 시작하며, 제일 처음 진행했던 프로젝트는 워터폴 방식의 개발방법을 차용했습니다. (뜻하지않게)
실용성이나 상용화는 둘째치고, 협업이 처음이었던 신입 개발자와 소프트웨어 QA가 처음이었던 QA였음으로
본격적인 실무 투입 전 햇병아리들에게 주어진 토이 프로젝트의 느낌이었습니다.
어디서 듣던 건 있어서 옛날부터 애자일 방법론을 써야한다, CI/CD를 도입해야한다 이런 추상적인 생각은 했었으나,
막상 진행하니 아무 생각없이 있다가 개발이 다 끝날때쯤이야 생각나서 부랴부랴 급하게 구축했습니다.
발등에 불똥떨어진 상태에서 급하게 탭댄스를 추듯 한 구축 과정에서 겪었던 경험들에 대해 공유해볼까 합니다.
1) 필요한 툴
1-1. Jenkins
CI/CD에서 빌드 및 배포를 담당하는 집사님이십니다.
파이프라인을 통해 GitLab에서 소스를 받아오고, Docker로 이미지를 빌드하고, Docker를 실행합니다.
그 외에도 of executor (동시에 실행할 수 있는 작업의 수) 설정과 node(작업을 실행하는 머신) 설정을 통한 병렬 빌드나,
Build Periodically로 특정 시간마다 빌드 할 수도 있고, Webhook을 통해 GitLab에 푸쉬되는 작업물을 트리거로 빌드할 수 도 있는 등 아주 유용한 툴입니다.
CI/CD에 핵심적인 역할을 하는 만큼, 밑에서 더 자세히 다룰 예정입니다.
1-2. Docker
가상환경을 세팅하고 빌드해서 배포할 수 있는 도커입니다.
가상환경의 이미지 특성 상 통합된 환경을 보장함으로, 서로 다른 컴퓨터에서도 동일한 결과를 보장해줍니다.
쉽게 예를들면, 이슈가 발견됐다고 개발자에게 들고 갔을때 '저는 잘 되는데요?'를 웬만큼 방지해줍니다.
현재 환경을 이미지로 빌드(build 명령어)하고,
서버에 올려 공유(push 명령어)하고,
공유된 이미지를 내려받고(pull 명령어),
이미지를 실행하는(run 명령어) 기능들이 핵심이라고 볼 수 있습니다.
저희는 순정 리눅스 이미지에 개발된 프로젝트의 실행에 필요한 의존성을 모두 설치한 상태로 이미지로 만들어 배포하고,
그 이미지를 기반으로 dockerfile로 build하고 run하는 방식으로 구현했습니다.
1-3. GitLab
개발자들의 창고라고 볼 수 있는 Repository 역할을 하는 깃랩입니다.
GitHub이 더 유명하고 잘 알려져있지만 협업을 위한 툴로서, 그리고 지금 새로 사용하기에는
GitLab이 더 좋을 것 같다는 내부 리서치 결과가 나와 저희는 GitLab을 사용하기로 결정했습니다.
이것에 관해서 QA 입장에서는 기본적인 저장소 기능을 제외하면
젠킨스와의 연동을 위한 Webhook 발급 및 적용, Branch 전략 구상(개발자와 함께)
이정도밖에 진행한 내용이 없어 사실 따로 더 적을만한 내용이 아직 없습니다.
2) 시행착오
체계적으로 차근차근 적용했다면 많은 것을 고려할 수 있었겠지만, 급하게 적용하느라 놓친 부분이 많았습니다.
놓친 부분부터 접근하자면 다음과 같습니다.
1. 프로토타입의 부재
처음 프로젝트를 시작할때 요구된 첫번째 명세는 '가장 단순한 기본 기능부터 구현하라' 였습니다.
하지만, 개발자나 저나 경험이 없는 상태에서 저 말을 들었을때 떠올린 것은 '일단 다 구현은 해놓은 상태' 였고,
개발이 끝났다는 사인을 들었을때는 사실 모든 개발이 완료된 상태의 빌드가 나온 후 였습니다.
애자일 방법론이 유행하게 된 이유는, 결과물을 빠르게 뽑아 피드백을 빠르게 도출하고 반영하여
시대의 흐름에 따라, 유저의 필요에 따라 변화하는 요구사항에 발빠르게 대응하기 위함이었으나
이것에 정면으로 맞서는 MZ 사원이 되버린 것입니다.
프로젝트가 끝나고 나서 생각해보니 '우리가 한거 완전 구닥다리 폭포수 모델인데?' 라는 생각이 들었고,
가장 필수적이고 단순한 기능부터 구현한 프로토타입 빌드를 만든 후,
그것을 통해 기본기능 검증과 UI/UX 견적을 내는 방향으로 진행했어야 하지 않나 하는 후회가 들었습니다.
2. 빌드노트
사실 기능이 많지않은 프로젝트였어서(상호작용 없이 특정 정보를 특정 조건에 따라 노출시켜주는 페이지였습니다.)
게임 QA를 할때도 자주 봤었던 빌드노트를 만들어야겠다는 생각은 하지않았었습니다.
하지만 애자일하게 개발을 진행한다면, 개발되고있는 기능과 개선이 필요한 항목에 대해
히스토리를 정리하는 빌드노트가 없다면 진척 상황을 알기 너무 어렵다는 생각이 뒤늦게 들었습니다.
이번엔 워터폴 방법으로 진행되었으므로 빌드노트를 작성했다면 그냥 영화의 엔딩크레딧 느낌이 되어버렸을 수 있겠으나,
추후부터는 빌드노트 작성 계획을 수립 후 진행하도록 프로세스를 정립했습니다.
3) 어떻게?
비록 워터폴 방식으로 진행했으나, 프로젝트 종료 후에도 지속적인 개선 작업은 진행되니
이 프로젝트의 CI/CD에 대한 기초적인 틀은 마련해두는게 좋다고 생각되어 작업을 진행했습니다.
먼저, 개발자와 QA의 역할을 분담했습니다.
개발자
- 소스 커밋
- 작업 내용 공유 (툴은 레드마인을 사용했습니다만, 협업 툴 아무거나 사용해도 무방합니다.)
- 이슈 디버깅
- Dockerfile 작성
QA
- 젠킨스/GitLab 프로젝트 및 아이템 구성
- 젠킨스 파이프라인을 통해 Git에 소스코드 변경점 커밋 시 자동으로 빌드 및 실행
- 젠킨스 파이프라인을 통해 특정 시간마다 페이지 진입하여 상태 체크(HTTP status, 데이터 정합성)
- 이슈 등록 및 트래킹
여기는 QA 블로그이므로(사실 개발자가 하는 일을 모르므로), QA 입장에서 했던 일에 대해 정리해보겠습니다.
1. 먼저, GitLab에 저장소를 생성 후 개발자와 Branch 전략에 대해 논의합니다.
저희는 main 브랜치 하나와 기능 별로 feature 브랜치를 신규 생성하는 간단한 방식으로 진행했습니다.
2. 그 다음, 생성된 저장소와 웹훅으로 연동되는 젠킨스의 아이템을 신규 생성합니다.
웹훅 방법에 대해서까지 포함하면 글이 너무 길어지므로, 검색해보는 것을 권해드립니다.
3. 젠킨스 파이프라인을 통해 코드를 작성합니다.
모든 코드는 프로젝트 상황마다 달라지므로, 대략적인 구상에 대해 소개해드리자면 다음과 같습니다.
1) GIT에서 코드를 받아오는 단계
2) 개발자가 작성한 Dockerfile을 빌드하는 단계
3) 빌드한 Docker를 실행하는 단계
4) 파이프라인 진행 간 모종의 이유로 실패 시, 설정한 이메일로 실패 알람이 전달되는 단계
이 모든 과정에 GitLab에 코드가 커밋 될 때 마다 자동으로 진행되도록 합니다.
4. 자동화 테스트 코드를 실행하기 위한 젠킨스의 아이템을 하나 더 신규 생성합니다.
테스트 코드는 selenium과 pytest를 사용했으며, 젠킨스의 Build Periodically 옵션을 이용하여
특정 시간마다 해당 페이지에 접근 후 테스트 코드를 돌리는 방법으로 진행했습니다.
테스트 코드 내에서 시간 조건을 거는 방법도 있었으나, 그렇게 하면 젠킨스 내에서 파이썬이 상시 가동되어야하여
젠킨스를 통해 조건을 거는게 더 낫다고 판단했습니다.
이것 역시 테스트가 실패하면 설정한 이메일로 알람이 전송되도록 세팅했습니다.
5. 이 모든 것과 별개로, 수동 테스트는 필수적으로 병행했습니다.
각종 예외사항, 사전조건, 변화하는 환경 모두 자동화를 하려면 할 수 있었으나,
코드 작성 및 유지보수에 드는 시간이 더 오래 걸리면 주객전도라고 생각되어 블랙박스 테스트를 항상 병행했습니다.
그리고 pytest로 assert를 걸어 확인하는 방법도 데이터 기반의 확인이다보니,
데이터상의 값은 정상인데 표기가 이상하다거나...(아직까지 그런 적은 없습니다만)
그런 이슈들을 방지하기위해서라도, 자동화 한 부분이라도 한번씩은 직접 확인하는 방향을 선호했습니다.
이번 프로젝트가 토이 프로젝트긴 하지만, 소프트웨어 QA로서 CI/CD의 코딱지만큼이라도 흉내낸 첫 프로젝트다보니
맨땅에 헤딩으로 많은 점을 배웠고 이후에 다른 프로젝트를 한다면 이번보다 많은 점을 보완할 수 있다고 생각이 듭니다.
감사합니다.
'CI CD' 카테고리의 다른 글
| 젠킨스 빌드 시간을 줄이는 여정 (0) | 2024.08.07 |
|---|