나는 프로젝트를 열심히 하던 찰나 변수의 위치를 바꿔버리는 어이없는 실수를 하였다.
function void hello(int a, int b){}
// 실수
hello(b,a);
// expect
hello(a,b);빠르게 찾을 순 있었고 문제는 해결했다. 하지만 이로인해 내 코드를 의심 할 수 있는 좋은 기회였다.
위 문제가 아니었더라도 협업하는 환경에서 문제가 자잘하게 많았다.
동시 병렬적으로 작업을 하다보니 코드의 충돌이 생기고 서로 빠른 주기로 개발은 하는데 리뷰시간이 아깝다는 핑계로 리뷰를 안하더니 막상 코드의 히스토리를 이해하기위한 리뷰가 더 길어지는 문제는 말해 뭐해다.
내가 겪은 경험들이 말해주는 바는 "지금까지 일해왔던 방식은 일하는 시간이 증가하고 코드의 품질을 높이지는 못한다." 이다
도입 허락해줘 ..
코드 스타일도 다르고. 쪼개서 해야하는 리뷰도 안하니 다른 사람이 짠 코드의 히스토리를 이해하지 못한다.
내가 짠 코드도 못 믿는다. 남이 짠 코드는 더더욱 신뢰할 수 없다. 누가 검증을 해 줄수 있는가 ?
- 개발 시간의 증가, 코드 신뢰도 하락
검증은 하지만 자기 PC에서만 한다는 것, 막상 배포하려고 하니 환경 문제가 생긴다.
- 개발 외 업무 증가
신뢰 할 수 없는 개발 주기안에서 열심히 개발을 하고 나니 남는 건 버그와 연장 근무뿐이 아니겠는가? from su8y
CICD 도구를 통해 개발 상태, 배포 상태 등을 한 눈에 확인이 가능하므로 매니저한테도 좋은 일이 아닐수가 없다.
일하는 사람이라면 효율적으로 일 할수 있는 방법에 대해서 고민을 해봐야한다. 이를 위해서 깃랩 CI/CD 파이프라인 구상을 해보려고 한다.
지속적인 통합/제공/배포
- ci: application 코드의 변경사항이 정기적으로 빌드 및 테스트(품질 검사 등)을 거쳐 공유 Repository에 병합이 되는 프로세스로 버그가 없고 좋은 application을 고객에게 전달하기 위한 초석입니다.
- cd: 개발을 신명나게 하고나서 배포하는 과정의 자동화 프로세스입니다.
전체적인 CI/CD 흐름
- 개발 후 배포 해야되는 브랜치로 Pull Requests(PR)을 보냅니다.
- 해당 PR에 대해서 build, test, image push 를 합니다.
- 실패했다면 사유와 알림을 알려줍니다.
- 해당 파이프라인을 통해 발생한 개발 서버의 URL을 댓글, 이메일, SMS 등으로 안내해줍니다.
반응형