극단적 인 불안을 겪지 않고 프로덕션 배포를 자동화하려면 어떻게해야합니까?

우리 매장에서는 개발, 테스트 및 통합 환경에 대한 자동 빌드 및 배포를 처리 할 때 소스 제어에 SVN을 사용하고 CI에 CruiseControl을 사용합니다.

이 모든 것이 원활하게 작동하지만 하드웨어 및 리소스 제약으로 인해 통합 환경은 프로덕션 환경과 같은 2 서버 부하 분산 환경이 아닙니다. 다른 모든 것은 동일하지만 통합 환경과 프로덕션 환경 사이의 유일한 차이점이 될 것입니다 (큰 환경이지만).

이론적으로 차이점은 앱 서버의 구성이 약간 다르며 배포 스크립트는 빌드 아티팩트를 하나의 서버 대신 두 개의 서버로 드롭해야하는 이유입니다. 그러나 왜 프로덕션 배포를 자동화하기에 너무 긴장합니까?!

나는 일반적으로 제어 괴물이 아니지만 프로덕션에 프로덕션을 수동으로 배포해야한다는 필견의 필요성을 항상 느낍니다. 동료들로부터 이것이 일반적으로 BAD Thing ™이라는 말을 들었지만, 이에 반대하지는 못했습니다.

수동으로 할 때 실제로 올바른 파일을 복사하고 실제로 앱 서버를 종료하고 성공적으로 닫혔는지 확인하고 서버를 실제로 시작한 다음 로그를 물리적으로 검사하여 확인합니다. 제대로 시작되었고 배포가 성공했는지 확인하십시오. 그것은 나에게 마음의 평화를줍니다.

자동 스크립팅 된 프로덕션 배포에 대한이 OR 인수에 대한 인수는 무엇입니까?

이에 대한 몇 가지 명백한 주장이 있습니다.

1. 당신이 떠나면 어떻게됩니까? 이 모든 정보는주의 깊게 문서화되어 있거나 대부분 머리에 있습니다. 자동화 된 스크립트는 다른 사람이 대신 할 수있는 훨씬 좋은 장소입니다.

2. 누구나 실수를합니다. 배치를 수행하는 사람이 피곤하고 관심을 기울이지 않는 시간이 올 것입니다. 그렇습니다. 배치는 시간이 많이 걸리는 행복한 평온한 장소에서만 이루어집니다. 실제로 긴급한 수정 프로그램을 출시하려고 할 때 서두르고 스트레스를받을 수 있습니다. 이것은 실수를 저지를 가능성이 가장 높으며 가장 비용이 많이 드는 시간입니다. 배포가 단일 스크립트 인 경우 실수 가능성이 제한됩니다.

3. 시각. 배포가 복잡 해짐에 따라 필요한 양이 증가합니다. 스크립트는 시작, 수동 확인 및 수동 전환이 필요합니다 (자동화 할 수도 있지만 편집증을 공유합니다).

공정 검증 및 자동화의 신뢰성으로 마음의 평화를 누릴 수 있습니다.

배포를 스크립팅하십시오. 그런 다음 프로세스가 시작되었는지, 파일이 제거되었는지 등을 수동으로 확인하십시오. 즉, 자동 단계 1-X가 실제로 발생했는지 확인하기 위해 자체 QA 스크립트를 작성하십시오.

여기서 핵심은 다음과 같습니다. 왜 검증 프로세스를 스크립트 할 수 없다고 생각하십니까?

내 배포 스크립트는 아카이브를 푸시하고 서비스를 다시 시작하지 않습니다. 배포의 각 단계에서 많은 색상으로 구분 된 정보를 인쇄하고 마지막에 이벤트 요약을 제공합니다. 프로세스가 실행 중이고 홈페이지가 200 상태 코드를 제공하고 있으며 모든 시스템과 서비스가 서로를 잘 볼 수 있음을 알려줍니다. 그런 다음 로그 파일, 4xx 및 5xx 수준 오류 및 주요 사이트 메트릭을 모니터링하는 스크립트의 일부가 아닌 별도의 서비스가 있습니다. 그런 다음 급격한 부정적인 영향이 발생할 경우 가능한 모든 매체 (이메일, txt 메시지 및 경보)를 통해 나에게 소리를 지 릅니다.

테스트를 실행하는 CI 서버와 CI 서버 사이에서 나는이 자동화 수준에서 말 그대로 배포하고 잊어 버렸습니다. 현재 프로세스의 안정성으로 인해 푸시 후 사이트에서 단일 페이지를 탐색하지 않아도되므로 원하는만큼 자주 배포 할 수있을뿐만 아니라 프로젝트의 새로운 개발자가 라이브로 업데이트 할 수 있습니다 탑승 후 몇 분 안에 사이트를 방문하십시오. 과거에는 모든 것을 전달하는 마스터 / 트렁크 지점에 커밋 한 후 CI 서버가 프로덕션에 자동 배포되도록했습니다. 그것이 내가 도구에 대해 얼마나 확신하는지입니다.

당신도 그래야합니다.

또한 원격 디버깅으로 프로덕션 시스템을 실행하고 수동으로 단계별로 진행합니까? 적절한 스크립트 작성은 프로그램 작성과 동일합니다. 가지고있는 모든 문제는보고 확인해야 할 사항을 나타냅니다.

문제가 발생하면 적절한 롤백 절차를 거쳐 메시지를 보내야합니다. 발생하는 모든 것은 나중에 기록 될 수 있습니다. 스크립트의 버전을 제어하고 테스트 사례를 설정할 수 있습니다.

그러나 수동으로 명령을 실행하는 경우 이러한 이점이 없습니다. 대신 단점 목록이 있습니다.

• 당신은 좋은 로그가 없습니다, 쉘 기록은 계산되지 않습니다
• 아무도 그것을하는 방법을 모른다
• 단계가 빠짐
• 점검은 때때로 이루어집니다
• 배포 할 일부 항목이 누락 될 수 있습니다.
• 시간이 더 많이 걸립니다
• 프로세스 중에 방해받을 수 있습니다

쉘에 모든 것을 입력 한 경우 적절한 스크립트는 거의 동일해야합니다. 이것이 우리가 bash 스크립트를 사용하는 이유 중 하나입니다. 당신이하는 일을 신뢰한다면 왜 모든 것을 기록하고 강화할 수 없습니까? 컴퓨터가 확인하기 때문에 더 나은 확인, 더 빠른 확인, 더 많은 확인이 발생할 수 있습니다.

나는 자극적 인 환경에서 뭔가 새로운 것을 시도하는 것이 약간 긴장하는 것을 이해할 수 있습니다. 잠재적 인 재난에주의하는 것은 Good Thing ^TM 입니다.

자동화 된 스크립팅도 Good Thing ^TM 이며 신중하게 접근하는 한 위험을 최소화하고 두려움을 줄일 수 있어야합니다. 제 충고는 이것입니다.

• 검사 목록 / 테스트 세트를 준비 (및 통합 환경에서 실습)하여 작동 여부와 문제가 무엇인지 신속하게 확인할 수 있습니다. 자세한 로깅이 도움이 될 수 있습니다.
• 모든 것을 백업하십시오. 잘못 작동하는 경우 복구 할 수 있도록 수동 롤백을 준비하고 연습하십시오.
• 실제 제품을 만들기 전에 최대한 많이 테스트하십시오. 통합 환경과 함께 좋은 방법 인 것 같습니다.
• 처음 시도 할 때 낮은 프로파일, 낮은 충격 변화에서 시도하십시오. 사소한 업그레이드 또는 패치와 같은 것. 아이디어는 잘못되면 낙진을 최소화하는 것입니다. 첫 달리기를 위해 높은 프로파일의 주요 업그레이드 (CEO 및 모든 경쟁 업체가보고있는 위치)를 선택하지 마십시오.

벨트 아래 몇 번의 성공적인 실행이 이루어지면 자신감이 커지고 곧 수동 배포를 어떻게 관리했는지 궁금해 할 것입니다.

프로덕션 환경에 수동 배포에 대한 가장 큰 논거는 다음과 같습니다. 사용자는 사람이며 실수를 저지를 것입니다. 의심 할 여지없이 슬픔을 일으킬만한 일을 잊어 버릴 때가있을 것입니다. 잘 작성된 자동 배포는 같은 경향이 없습니다. 여전히 엉망인 프로덕션 배포가 가능하다는 것은 사실이지만 자동화 된 배포에는 해결해야 할 버그가 있기 때문입니다.

내 경험상 프로덕션에 대한 자동 배포의 이점은 엄청납니다. 가장 큰 문제는 주말에 협력하지 않는 수동 배포 프로세스를 진행하는 대신 재미있게 놀 수 있다는 것입니다.

프로덕션 배포를 자동화하기위한 몇 가지 주요 사항은 다음과 같습니다.

• 한 번에하지 마십시오! 자동 배포 작성을 천천히 시작하십시오. 먼저 별도의 비 프로덕션 환경을 설정하고 배포 자동화를 시도하십시오. 자동화 된 배포에 대한 신뢰를 쌓고 나면 프로덕션 배포에 대한 생각을 시작할 수 있습니다
• 릴리스 및 배포를 매우 자주 시작하십시오! 릴리스 대기중인 4 개월 코드가없는 경우 자동 배포를 훨씬 쉽게 수행 할 수 있습니다. 작은 기능과 버그 수정을 일주일에 여러 번 릴리스하십시오. 이 릴리스 스타일의 장점은 과소 평가 될 수 없습니다!
• 자동화 된 테스트를 통해 프로덕션 환경이 제대로 작동 할 것이라는 확신을 가지십시오. 다시 말하지만, 이것은 구축하는 데 시간이 걸리지 만 매우 중요합니다. 자동화 된 테스트는 항상 수동 승인 테스트보다 낫습니다. 물론 수동 수락 테스트는 괜찮지 만 자동화 된 테스트를 통해 프로덕션 환경에 배포해야하는지 여부를 알 수 있습니다. 이 자동화 된 지속적인 전달의 전체 프로세스를 가능하게하는 열쇠입니다. 테스트에 통과하지 못하면 프로덕션 환경에 배포하지 않는 것입니다.

라이브 서버에서 스크립트를 실행하십시오. 작동하고 몇 번 잘 작동하면 완벽하게 확신합니다.

그러나 배포 스크립트보다 실수를 범할 가능성이 높습니다.

사람들은 컴퓨터를 실수하지 않습니다.

스크립트를 한 번 작성하고 철저히 확인한 후 한 줄씩 진행하십시오. 그때부터 배포 할 때마다 작동하는지 확인할 수 있습니다.

손으로하면 실수를해야합니다. 어쩌면 당신이해야 할 모든 것을 적었을 수도 있지만 실수하기는 너무 쉽습니다. web.config 파일을 제외한 모든 파일을 복사해야합니까? 언젠가는 덮어 쓸 것이라고 내기 할 수 있습니다. 스크립트는이 실수를하지 않습니다.

극단적 인 불안을 겪지 않고 프로덕션 배포를 자동화하려면 어떻게해야합니까?

프로덕션 배포를 자동화 할 때 경험할 수있는 극심한 불안은 아마도 두 가지 신념에 근거 할 것입니다.

1. 언젠가는 일부 배포 단계가 실패하고 자동화 된 스크립트가이를 간과 할 수있는 동안 사용자 또는 다른 사람이 실패에서 빠르게 복구 할 수 있습니다.

2. 간과 된 생산 실패는 극적인 결과를 초래합니다.

실패를 피하는 것 외에 약 2를 할 수있는 일은 거의 없습니다. 따라서 1에 집중합시다.

기존 시스템에서 약간 개선 된 저렴한 솔루션은 반자동 배포 절차를 사용하여 설치의 각 단계가 끝날 때마다 유효성 검사를 기다리는 것입니다. 반자동 솔루션을 사용하면 일관성 및 생식과 같은 완전 자동 솔루션의 이점을 누릴 수 있지만 현재 진행중인 진행 상황을 모니터링하고 오류를 복구 할 수 있습니다.

반자동 스크립트와 비오토프 (회귀 테스트 등)는 설치 절차에서 발생하는 오류와 복구 방법에 대해 수집하는 지식의 매개체 역할을 할 수 있습니다.

내가 좋아하는 것은 준비 또는 QA에서 배포를 테스트 할 수 있으며 제품을 실행할 때 동일한 단계가 발생한다는 것을 알고 있습니다.

수동으로 수행하면 단계를 잊어 버리거나 순서가 잘못되는 것이 더 쉽습니다.

... 하드웨어 및 리소스 제약으로 인해 통합 환경은 프로덕션 환경과 같은 2 서버로드 밸런싱 환경이 아닙니다. 다른 모든 것은 동일하지만 통합 환경과 프로덕션 환경 사이의 유일한 차이점이 될 것입니다 (큰 환경이지만).

위에서 주어진 것처럼, 나는 아마도 당신만큼 불안 할 것입니다.

한 번 SLB에 배포되는 자동화 된 스크립트를 검토하고 테스트 했으며로드 밸런스 설정에서 사전 테스트 하지 않고 수동으로 작업하는 것을 선호한다고 생각합니다.

찌르기 같은 테스트 설정 외에도 제 마음의 평온에 중요한 영향을 미친 또 다른 것은 개발자 가 제작 한 다른 팀, 즉 프로덕션 환경을 유지하는 것이 유일한 녀석에 의한 찌르기 배포 입니다.

• 프로젝트 중 하나에서 개발자 팀 대표로 배포하는 데 도움을주었습니다. 배포하기 전에 그들은 내 지침을 검토하고 있었고 배포하는 동안 온라인에 앉아 문제가 있는지 상담 할 준비가되었습니다. 그때, 나는 그 분리 에 감사하는 법을 배웠습니다 .
   
  더 빠르지는 않습니다 (왜 그렇습니까? 나는 5x-10x보다 더 자주 배포를 테스트했습니다). 큰 차이가 집중되었습니다. 내 머릿속에는 코딩, 디버깅, 새로운 기능과 같은 "주요"항목이 항상로드되어 있습니다. 그와는 반대로, 그들의 주요 내용은 단지 생산 유지 관리였으며 그에 중점을 두었습니다.
   
  집중할 때 뇌가 얼마나 잘 작동하는지 놀랍습니다. 이 사람들, 그들은 훨씬 더 세심하고 나보다 훨씬 적은 실수를 저질렀습니다. 그들은 단지 그 물건을 나보다 잘 알고있었습니다. 그들은 심지어 나 자신의 테스트 배포를 더 쉽게 만들어주는 것을 가르쳐주었습니다.

코드를 모든 환경으로 이동하는 데 사용하는 배포 스크립트를 작성하십시오. 우리는 정확히 동일한 배포 프로세스를 사용하여 코드를 dev, qa, staging 및 최종적으로 프로덕션으로 옮깁니다. 우리는 매일 여러 차례 배포하고 QA에 배포하므로 배포 스크립트가 정확하다는 확신을 얻었습니다. 기본적으로 자주 사용하여 지옥을 테스트하십시오.

1. 단순화하십시오. 변경 프로세스는 rsync 파일이어야하며 SQL 스크립트를 실행하면됩니다.
2. 자동화
3. 테스트.

자동화해야하는 이유는 테스트가 가능하고 반복 가능하며 모든 예상 상황에서 올바르게 작동하도록 신뢰할 수있는 것을 얻는 것입니다.

상황에 따른 변경 사항에 대해서는 여전히 철회 계획이 필요하며 자동화되어야합니다.

환경이 실제로 민감한 경우 발생하는 프로세스를 계속 관찰하고 싶지만 재생산 할 수 없으므로 수동으로 수행하지 마십시오.

자동화 스크립트를 사용하여 프로덕션 환경에 배포하는 것은 전적으로 가능합니다. 그러나 그렇게하려면 몇 가지 일을 할 수 있어야합니다.

1. 이전 버전으로 안정적으로 롤백하십시오.
2. 배포가 성공적으로 적용되었고 유효한 트래픽에 응답하고 있다는 긍정적 인 확인을 얻습니다.
3. 동일한 스크립트를 사용하는 비슷한 개발 환경과 QA 환경이 있습니다.

스크립트는 오전 2 시로 인해 명령이 빠질 수없고 피곤하기 때문에 몇 가지 장점이 있습니다.

그러나 스크립트는 여전히 실패 할 수 있습니다. 때때로 오류는 스크립트 디자인에 있지만 네트워크 나 정전, 파일 시스템 손상, 메모리 부족으로 인해 발생할 수도 있습니다 .....

그렇기 때문에 스크립트가 실행 된 후 라이브 트래픽이 활성화되기 전에 새 배포가 요청을 실행하고 처리하는지 확인하는 정의 된 테스트 단계도 따라야합니다.

1. 일이 잘못되면 처음으로 더 큰 창을 설치하십시오

2. 배포 프로세스를 두 부분으로 나눕니다. 에이. 백업 (수동)-배포 중에 문제가 발생할 경우 자신감을 가져야합니다.

   비. 배포 (자동)

처음으로 자신있게 배포 할 수 있습니다. 백업 프로세스도 자동화 할 수 있습니다.