애자일 지속적 통합
DevOps와 지속적 통합, 전달 및 배포(CI/CD)의 전 과정으로서 애자일은 이런 접근법과 밀접한 관련이 있습니다. 애자일의 기반 철학을 이해하면 애자일을 구현하는 CI/CD 파이프라인을 구현하면서 CI/CD의 장점을 최대한 활용할 수 있습니다.
안타깝게도 프레임워크, 전략, 컨설턴트 등이 수년 간 애자일의 핵심 가치를 희석시키고 엄격한 규칙으로 전락시켰습니다. 그러나 원칙을 이해하지 않고는 효율적으로 적용하기가 훨씬 어렵습니다.
애자일 원칙
무엇보다도 애자일은 소프트웨어 개발 프로세스에 관한 사고방식입니다.
애자일은 원활히 작동하는 소프트웨어를 제공하는 것이 목표라는 점과 변화를 수용하고 개인들 간의 협업을 장려하는 것이 계약된 요구사항에 따라 만들어진 계획을 엄격히 따라가는 것보다 더 효율적인 방법이라는 점을 인식합니다.
애자일 선언에 설명된 원칙은 이런 가치를 상세히 설명하며 이를 시행하기 위한 기술도 제공합니다. 여기에는 역량 있고 협력하는 팀을 만들고 팀이 변화에 대응할 수 있도록 빈번하게 반복적인 주기로 잘 작동하는 소프트웨어를 제공하는 것이 포함됩니다.
이유는 간단합니다. 착수 시에 요구사항을 못박아 버리고 이를 위해 계획을 엄격히 따르면 더 많은 것을 알아가고 사용자들의 환경이나 수요가 변화할 때 빌드 중인 제품을 이에 적응시킬 유연성을 잃게 됩니다. 애자일 접근법은 최종 목표를 설정하고 점진적으로 이를 달성할 방법을 구체적으로 찾는 것입니다.
CI/CD로 애자일 활성화
애자일 원칙은 DevOps 운동에 영향을 주었고, 이는 CI/CD 방법론의 시초가 되었습니다.
초기에 애자일의 초점은 개발 팀의 작업 방식이었으나 DevOps는 하위 프로세스까지 영역을 확장했고 코드가 작성되고 릴리스될 때까지의 과정을 포함하게 되었습니다.
DevOps는 부서간 장벽을 허물고 팀 간의 협력을 통해 제대로 작동하며 유용한 소프트웨어를 사용자에게 전달하는 공통의 목표를 달성하는 것이 중요하다는 것을 강조합니다. 지속적 통합, 전달 및 배포는 DevOps 절차로서 품질과 타협하지 않으면서도 빠르게 소프트웨어를 배포하는 것을 목표로 합니다.
프로세스에서 가능한 한 최대한 많은 과정을 자동화함으로써 지속적 통합 환경은 빠른 피드백 빌드를 제공하여 사용자에게 소프트웨어를 릴리스하는 데 걸리는 시간을 줄입니다.
애자일과 DevOps의 역사를 고려한다면 빌드 파이프라인에 포함된 일부 요소가 애자일 방식으로 작업하는 데 도움이 된다는 것은 놀라운 일이 아닙니다. 먼저 CI에서 추천되는 "일찍, 자주 커밋"하는 방식은 작은 배치로 작업하는 것을 장려합니다.
기능을 작은 단위로 나누는 것은 반복적인 빌드 및 릴리스 프로세스에 필수적입니다. 모든 커밋이 CI/CD 워크플로 내에서 진행되고 잠재적으로 릴리스될 수 있게 하는 것이 목표이므로 각 커밋은 최종적으로 작동하는 결과물로 이어져야 합니다. 그러므로 이런 접근법을 택하면 작동하는 소프트웨어를 개발하는 데 집중할 수 있습니다.
애자일과 DevOps는 모두 협업과 소통의 가치를 강조합니다. DevOps의 초기 주안점은 개발 및 운영 간의 협업이지만 그 이점은 더 광범위할 수 있습니다.
여러 단계로 나뉘는 환경을 빌드 파이프라인에 포함시키고 대시보드를 통해 각 빌드에서 무엇이 바뀌었는지 보여 줌으로써 마케팅, 디자인 혹은 보안 팀과 같은 조직 내의 다른 부서와 진척 상황을 공유하고 피드백을 받을 수 있습니다.
CI/CD 파이프라인의 중심에는 코드 변경 사항에 대하여 빠르게 피드백을 전달하고 빌드 품질을 보장하는 자동화 테스트가 있습니다. 각 커밋에 대해 자동화 테스트를 시행하는 것은 제대로 작동하는 소프트웨어를 개발하는 데 있어 중요한 과정입니다.
애자일 아젠다에서 사용자에게 자주 소프트웨어를 릴리스하는 것은 높은 중요도를 가지며 CI/CD 파이프라인은 이 원칙을 가능하게 하는 핵심입니다. 릴리스 프로세스 과정을 자동화하여 팀들이 릴리스 속도를 매우 높이고 매일 혹은 매 시간마다 변경 사항을 배포할 수 있었습니다. 이는 선언이 작성되었을 때 상상했던 것보다도 더 빈도수가 높습니다.
마지막으로 지속적인 피드백 사이클은 CI/CD 파이프라인에 중심을 구성하며 빌드 중인 소프트웨어와 이를 가능하게 하는 프로세스 모두가 지속적으로 개선될 수 있게 합니다. 또한, 팀이 정기적으로 프로세스를 되돌아보고 이에 따라 조정해야 한다는 애자일 원칙을 강화합니다. 피드백 루프에서 빌드하고 이를 경청하는 것은 선언에서 주창하는 지속적인 개발 페이스를 설정하는 데 도움이 됩니다.
애자일 조직 만들기
CI/CD 파이프라인을 구현하는 것은 애자일 사고방식을 장려하지만 애자일이 처음 정의된 이후 널리 퍼진 다양한 애자일 프레임워크나 솔루션보다 효과적인 것은 아닙니다.
따라서 CI/CD 방법론의 흔한 안티패턴 중 일부는 생각보다 조직이 애자일을 잘 구현하지 않는다는 지표로 사용될 수 있습니다.
지속적 통합 환경을 위한 효과적인 빌드 파이프라인을 구동하고 애자일 원칙을 채택하는 데 자주 방해가 되는 요소는 릴리스 프로세스에 여러 수동 단계를 도입하는 것입니다. 여기에는 새로운 빌드가 프로덕션(혹은 스테이징)으로 배포되기 전에 자문위원을 변경하거나 상세한 변경 사항 및 리스크 평가를 제공하도록 요구하는 것이 포함됩니다.
이런 절차의 목표는 일반적으로 릴리스를 일정 수준으로 감독 및 통제하는 것입니다. 그러나 이런 절차는 프로세스의 속도를 중대하게 저하하며 빌드에 대한 신뢰도를 확보하는 자동화 테스트 절차의 목적을 무시합니다.
측정 지표를 사용하여 CI/CD 파이프라인의 견고함을 보여주면 사람들의 우려를 해소할 수 있습니다. 이와 동시에 대시보드와 자동화된 알림으로 수작업을 줄이면서 파이프라인에서 나오는 변경 사항에 대해 당사자들에게 알릴 수 있습니다.
다른 일반적인 이상 징후는 프로세스와 배치 변경사항을 느리게 하여 릴리스의 빈도수를 줄이는 요청이 발생하는 것입니다.
일부 제품에서는 변경사항을 1주 혹은 2주 간격의 업데이트로 그룹화하는 것이 적절할 수 있지만, 이보다 빈도수가 낮게 되면 프로덕션에서 변경사항을 확인하는고 여기서 얻는 피드백을 다음 과정에서 활용하는 이점을 놓칠 수도 있습니다.
애자일 지속적 통합, DevOps 및 CI/CD 절차를 하는 이유를 알리고 조직내 모든 계층의 참여를 유도하는 것은 부드러운 전환에 도움이 됩니다.
CI/CD와 애자일을 근본적으로 방해하는 것 중 하나는 신뢰의 부족이며, 이는 팀들이 필요한 업무를 수행하는 데 필요한 역량이 부족해지는 결과로 이어질 수 있습니다. 결정이나 변경을 위해 여러 수준의 동의를 받게 하는 것은 프로세스의 속도를 늦추고 빠른 피드백의 이점을 줄입니다.
역량 있는 팀에는 제대로 작동하는 소프트웨어를 개발할 구성원이 필요하며 팀이 업무를 할 수 있도록 경영진이 적절한 도구와 환경도 제공해 주어야 합니다.
마무리
애자일은 종종 특정한 방법으로 적용되어야만 하는 고정된 규칙으로 잘못 설명되기도 합니다. 안티패턴에 주의하면서 근거를 이해하고 원칙을 조직에 적용하면 애자일 지속적 통합 사고방식을 장려할 수 있습니다.
CI/CD 방법론을 채택하면 애자일 가치를 실현하고 반복적인 개발 사이클과 빈번한 릴리스의 이점을 실현하는 데 도움이 됩니다.