Tackling Challenges in Integrating Multi-community CI/CD Pipelines - Ericsson의 발표 정리
CD Summit NA 2019에서 관심 가는 몇가지 발표를 정리해본다.
주제 : Tackling Challenges in Integrating Multi-community CI/CD Pipelines - Emil Backmark, Ericsson
동영상 : https://www.youtube.com/watch?v=aOIaa602CqA
발표자 Emil님은 20년 경력 보유
Ericsson이 CI/CD journey에서 겪은 문제들, 해결한 방법들을 이야기한다.
10~15년전 :
- waterfall 방식 개발방법 사용
- development team, integration team, system testing team 등으로 구성
- integration, system test가 자동화되지 않음
- cron 활용하여 shared folder에 있는 테스트 스크립트 수행
그 후 :
- cron job 대신 hudson 도입, regression test에 활용
- 개발팀은 가끔 코드 변경시 unit test 수행
- 형상관리도구로 clearcase를 사용 (아직까지 일부는 사용하고 있다고...)
- 개발팀과 integration팀 간의 파이프라인을 연결하여 automated integration을 달성했으나 integration test와 system test는 대부분 scheduled
- test 스크립트가 형상관리 안으로 들어옴 (파이프라인 연결이 가능케 됨)
그 후 :
- hudson은 jenkins로 변경
- clearcase는 git으로 변경
- 더 많은 테스트 코드가 git으로 들어옴
- 이 때 continuous integration이 유행어(buzzword)가 됨
- system test팀과 integration팀 간의 파이프라인 연결로 수동으로 전달하는 것이 줄어들고, commit부터 품질 확보까지의 시간이 감소됨
그 후 :
- 더 많은 dependency가 integrate됨
- 자동화 수준을 높여 품질은 좋아지고 배포 프로세스에서 더 정확한 예측을 할 수 있게 됨
- 시장 변화에 빠르게 대응할 수 있게 되었고 new feature와 수정을 고객에게 빠르게 전달할 수 있게 됨
- 그러나 integration chain이 다루기 힘들어짐 (여러 팀이 팀마다 각자 jenkins를 운영)
- 이를 중앙에서 jenkins instance를 제공해줬지만 팀마다 요구하는 plugin이 다양해 plugin 관리 힘들어짐
그 후 :
- 팀과 제품은 많아지고 그것들을 전부 integrate해야 함
- 시간대가 다른 팀이 많고 팀마다 build, integration 요구사항과 사용하는 tool이 다름
- commit이 파이프라인의 어디에 와있는지 알기 어려워짐
- configuration management team이 release에 어느 수정이 포함되어 있는지, 시험이 얼마나 잘 됐는지 찾는 수작업들이 증가
정리하면, 첼린지는
- 팀/제품의 증가
- visibility
- traceability
- KPIs
- Including Open-source
이를 해결하기 위해 tool간의 interoperability 중요성 부각,
- open stack - kubernetes - jenkins 구성처럼 infra, orchestration, application tool간 연동, 메시지 전달이 어려움
해결책으로
- message, event 전달을 위한 protocol language를 만들어 복잡한 시스템간의 연동에 사용
- 이를 통해 CI/CD 파이프라인 전체를 시각화하고 측정할 수 있게 됨
- 그 프로토콜이 Eiffel (https://eiffel-community.github.io/) (발음은 아이펠) 이다. 다양한 툴간의 메시지 전달을 위해 이 프로토콜을 사용했으면 하고 cd foundation의 다수가 참여해주길 희망
결국 자사의 오픈소스 대중화를 꾀하는 것이나
우리가 갈 길은 멀었다는 것을 느낌...