느린 배포로 인한 회의 (2015)
(tidyfirst.substack.com)느린 배포가 회의를 유발함
- 소프트웨어 설계는 인간 관계의 연습임. 소프트웨어 개발에 사용하는 다른 기술들도 마찬가지임.
- "코드를 배포할 수 없을 만큼 회의가 많다"는 엔지니어의 불만은 배포 용량의 한계로 인해 발생할 수 있음.
- Chuck Rossi는 Facebook에서 한 번의 배포에 처리할 수 있는 변경 사항의 수가 고정되어 있다고 관찰함. 더 많은 변경 사항을 원하면 더 많은 배포가 필요함.
- Facebook은 지난 5년 동안 배포 속도를 주간에서 일일, 하루 세 번으로 증가시켰으며, 모바일 앱 배포 주기도 6주에서 4주, 2주로 줄였음.
- "배포당 변경 사항"은 비탄력적인 지표로, 개선은 가능하지만 시간이 걸림. 변경 사항이 현재 임계값을 초과하면 변경 사항 수를 줄여야 함.
- 조직적 오버헤드를 증가시키면 긍정적 피드백 루프가 시작됨: 작업량 감소 -> 압력 증가 -> 실수 증가 -> 배포당 변경 사항 감소 -> 오버헤드 증가 -> 작업량 감소.
- 더 많은 변경 사항을 처리하려면 배포 용량을 늘려야 함. 배포 주기를 줄이거나, 배포당 변경 사항을 늘리는 방법이 있음.
- 오버헤드를 줄이려는 시도는 결국 회의로 이어질 수 있음. 이는 너무 많은 코드를 배포하려는 시도를 막아줌.
소프트웨어 설계: Tidy First?
- 소프트웨어 설계는 인간 관계의 연습임. 기술을 향상시키는 것이 관계를 개선하는 방법 중 하나임.
Hacker News 의견
-
배포의 위험을 줄이는 방법으로 테스트와 조직적 특성을 개선하는 것이 중요하지만, 유일한 접근법은 아님
- 배포당 변경 사항의 수를 줄이는 것이 더 효과적임
- 작은 변경 사항을 자주 배포하면 더 빨리 가치를 전달하고 작은 실패를 경험할 수 있음
- 카나리 배포 및 점진적 롤아웃과 결합하면 배포가 더 이상 큰 위험이 아님
- DORA 연구와 Accelerate, The Phoenix Project, The Goal에서 이 접근법을 지지함
-
"소프트웨어 문해력"이라는 개념을 설명하려고 함
- 회사가 코드로 운영될 수 있는 능력을 의미함
- 모든 의사 결정자가 코드에 집중하지 않으면 소프트웨어 문해력이 부족한 것임
- 회사는 새로운 개념으로 운영될 수 있어야 함
-
CI 파이프라인에서 테스트 시간이 길어져 회복에 집중하기로 결정함
- 테스트를 단순화하고 회복에 집중하여 배포 전략으로 카나리를 사용함
- 이 접근 방식이 신선한 경험이었음
-
조직은 배포 개선을 방해할 수 있음
- 관료주의와 싸우는 것은 대부분의 조직에서 불가능함
- 느린 배포가 문제이지만 유일한 문제는 아님
-
큰 변화에 대한 두려움으로 인해 테스트가 증가함
- 회의가 목표가 되는 경향이 있음
- 비기술적 관리와 기술적 변화를 이끄는 방법에 대한 조언이 필요함
-
CloudFormation이 느린 이유에 대한 질문
-
마이크로서비스는 배포 빈도를 수평적으로 확장할 수 있게 함
-
소프트웨어 성능, 즉 인간의 성능이 중요함
- 빠른 반복과 위험 감소를 위해 빠른 테스트 자동화가 필요함
-
빠른 배포는 사건 대응 회의를 유발함