1 주일 릴리스주기 : 이것을 어떻게 실현할 수 있습니까?

우리 회사 (3 살짜리 웹 산업 스타트 업)에서, 우리는 제품 팀에 "아아, 이것이 지금 위기 패치입니다!"라는 말을 자주 겪고 있습니다. (모두가 아닌가?)

이는 자체 포함 된 엔지니어링 직원의 생산성 (및 사기)에 영향을 미칩니다. 경영진은 이러한 당일 요청의 빈도를 줄이는 방법에 대해 시간을 보냈으며 매주 릴리스 할 솔루션을 제안했습니다. (이전에 우리는 2 주에 한 번씩 일을했는데 보통 2 일 정도 걸립니다.)

13 명의 개발자와 6 명의 현지 / 9 해외 테스터가 있습니다. 이론은 다른 개발자 중 한 사람의 특정 전문 지식이 필요한 작업이 나오지 않는 한 4 명의 개발자 (및 모든 테스터) 만 짝수 릴리스에서 작업 할 것입니다. 각주기에는 2 일의 개발 작업과 2 일의 QA 작업 (1 일 범위 지정 / 심사 / ...)이 포함됩니다.

내 질문은 :

(a)이 길이의 릴리스주기에 경험이있는 사람이 있습니까?

(ᄂ)이 길이의 릴리스주기에 대해 들어 본 적이있는 사람이 있습니까?

(c) 만약 (a) 또는 (b)라면, 지구상에서 어떻게 작동합니까? (피해야 할 함정 등도 인정됩니다.)

(d)이 노력이 실패하면 어떻게 피해를 최소화 할 수 있습니까?

매주 또는 훨씬 더 자주 배달 할 수 있습니다. 현재로서는 일반적으로 2 주마다 릴리스되지만 다음주기를 기다렸을 경우 파트너 중 한 곳으로부터 통지없이 도착한 기능을 배포하는 것은 드문 일이 아닙니다. 다음 몇 달 후 어느 시점에서 나는 표준으로 지속적인 전달 (항목이 '완료되면 실용적으로 릴리스 되 자마자 릴리스 됨)'으로 이동하길 원하지만, 아직 확신 할 수는 없다. 멀리.

중요한 것은 웹 사이트에서 자동화 된 테스트 (단위 테스트 및 엔드-투-엔드 승인 테스트 / 실행 가능 사양)를 모두 필요로한다는 것입니다. 이것은 또한 빌드가 완전히 자동화되었음을 의미합니다. 수용 수준에서는 키워드 접근 방식 덕분에 유지 관리 가능한 테스트 스위트를 신속하게 구축하는 데 탁월한 로봇 프레임 워크 를 사용 합니다. 모양과 느낌을 위해 현장 테스터가 약간의 검사를 수행하지만 인도에는 여러 브라우저에서 더 철저한 검사를 수행하는 두 명의 남자가 있습니다 (예 : BrowserLab 과 같이 스크린 샷을 찍어 이러한 종류의 문제를 해결하는 사이트가 있습니다) ).

배포를 완전히 자동화하지는 않습니다 (마지막 단계는 수동 개입이 필요하며 이는 우리에게 중요한 결정입니다). 그러나 짧은 배포 주기로 올바른 데이터베이스 연결이 사용되고 있는지 확인하는 등 모든 작업을 자동화합니다. 이런 종류의 실수로 너무 쉽게 실수 할 수 있습니다.

당신이 확인하고 싶을지도 모르는 지속적인 배달에 관한 최근의 좋은 책이 있습니다. 지금까지 읽은 내용은 다음과 같습니다. Continuous Delivery : 빌드, 테스트 및 배포 자동화를 통한 안정적인 소프트웨어 릴리스

요약하면 고도로 훈련 된 팀, 높은 수준의 자동화 및 무엇보다도 그 자동화에 대한 매우 높은 신뢰가 필요합니다. 나에게 당신의 경우에 매주 주기로 이동하는 것은 실수 일 수 있습니다-위기 패치는 다른 문제를 암시하고 그것을 제거하기 위해 노력해야합니다. 템포를 올리면 상황이 더 나빠질 수 있습니다 ...

계속해서 "위기 해제"모드에 있다면, 한 걸음 물러서서 코드와 프로세스를 재평가하는 것이 더 현명하다고 말하고 싶습니다. 분명히, 계속 반복되는 어떤 종류의 실패가 있습니다.

실제 프로덕션 규모로이 작업을 수행하는 것이 완전히 가능하지는 않지만 적어도 한 명의 선임 멤버와 일부 다른 개발자 및 테스터가이 평가에 전념하는 것이 좋습니다.

"한 번에 4 번 접근하는 것"은 나에게 명백한 승자처럼 들리지 않습니다. 이는 지속적인 컨텍스트 전환을 의미하며 효율성이 훨씬 낮습니다.

끊임없이 변화를 위해 서두르고 있다면, 그러한 변화에 실수를 저지르고있을 때 다른 것을 깨뜨릴 가능성이 훨씬 높다는 것을 기억하십시오.

소프트웨어 업계에서는 1 주일보다 짧은 릴리스주기가 확실히 달성되었습니다. 그들은라는 기술을 사용 연속 전달 (또한 연속 배포 ).

하루에 50 번 출시되는 회사가 있습니다. 이 블로그 게시물은 그들이 어떻게 그것을 설명합니다 .

경영진은 이러한 "위기 직종"의 빈도를 줄이는 방법에 대해 어느 정도 시간을 투자했으며 매주 릴리스 할 솔루션을 제안했습니다.

당신의 관리가 세계 챔피언 인 것 같습니다 ... 왜 팀 정신에 intead에 투자하지 않습니까? 문제가 그들 스스로 사라지는 것을 보게 될 것입니다.

(a) + (b) IMHO, 팀 규모에 따라 최대 2 주가되어야합니다. 일주일 동안 한 사람의 쇼 또는 아주 작은 팀 (2 또는 3과 같은)을 위해 일할 것입니다.

(c) + (d) 그러나 팀이나 프로젝트의 규모에 관계없이 가장 먼저 수행하는 작업 중 하나는 빌드 및 배포를 자동화하는 것입니다. 프로젝트 초기에 그렇게함으로써 몇 주가 걸리지 않으면 며칠을 절약 할 수 있습니다.

한 번의 클릭으로 배포를 완료해야합니다. 소스에서 스테이징으로, 스테이징에서 프로덕션으로. 이를 가능하게하는 많은 도구가 있습니다. Ant / nant 에서 Automated Build Studio 와 같은 매우 무거운 것들에 이르기까지 .

백업, 알림,보고 등을 포함한 파일 배포에서 데이터베이스 업그레이드까지 모든 것을 자동화 할 수 있습니다.