우리 매장에서는 개발, 테스트 및 통합 환경에 대한 자동 빌드 및 배포를 처리 할 때 소스 제어에 SVN을 사용하고 CI에 CruiseControl을 사용합니다.
이 모든 것이 원활하게 작동하지만 하드웨어 및 리소스 제약으로 인해 통합 환경은 프로덕션 환경과 같은 2 서버 부하 분산 환경이 아닙니다. 다른 모든 것은 동일하지만 통합 환경과 프로덕션 환경 사이의 유일한 차이점이 될 것입니다 (큰 환경이지만).
이론적으로 차이점은 앱 서버의 구성이 약간 다르며 배포 스크립트는 빌드 아티팩트를 하나의 서버 대신 두 개의 서버로 드롭해야하는 이유입니다. 그러나 왜 프로덕션 배포를 자동화하기에 너무 긴장합니까?!
나는 일반적으로 제어 괴물이 아니지만 프로덕션에 프로덕션을 수동으로 배포해야한다는 필견의 필요성을 항상 느낍니다. 동료들로부터 이것이 일반적으로 BAD Thing ™이라는 말을 들었지만, 이에 반대하지는 못했습니다.
수동으로 할 때 실제로 올바른 파일을 복사하고 실제로 앱 서버를 종료하고 성공적으로 닫혔는지 확인하고 서버를 실제로 시작한 다음 로그를 물리적으로 검사하여 확인합니다. 제대로 시작되었고 배포가 성공했는지 확인하십시오. 그것은 나에게 마음의 평화를줍니다.
자동 스크립팅 된 프로덕션 배포에 대한이 OR 인수에 대한 인수는 무엇입니까?
답변
이에 대한 몇 가지 명백한 주장이 있습니다.
-
당신이 떠나면 어떻게됩니까? 이 모든 정보는주의 깊게 문서화되어 있거나 대부분 머리에 있습니다. 자동화 된 스크립트는 다른 사람이 대신 할 수있는 훨씬 좋은 장소입니다.
-
누구나 실수를합니다. 배치를 수행하는 사람이 피곤하고 관심을 기울이지 않는 시간이 올 것입니다. 그렇습니다. 배치는 시간이 많이 걸리는 행복한 평온한 장소에서만 이루어집니다. 실제로 긴급한 수정 프로그램을 출시하려고 할 때 서두르고 스트레스를받을 수 있습니다. 이것은 실수를 저지를 가능성이 가장 높으며 가장 비용이 많이 드는 시간입니다. 배포가 단일 스크립트 인 경우 실수 가능성이 제한됩니다.
-
시각. 배포가 복잡 해짐에 따라 필요한 양이 증가합니다. 스크립트는 시작, 수동 확인 및 수동 전환이 필요합니다 (자동화 할 수도 있지만 편집증을 공유합니다).
답변
공정 검증 및 자동화의 신뢰성으로 마음의 평화를 누릴 수 있습니다.
배포를 스크립팅하십시오. 그런 다음 프로세스가 시작되었는지, 파일이 제거되었는지 등을 수동으로 확인하십시오. 즉, 자동 단계 1-X가 실제로 발생했는지 확인하기 위해 자체 QA 스크립트를 작성하십시오.
답변
여기서 핵심은 다음과 같습니다. 왜 검증 프로세스를 스크립트 할 수 없다고 생각하십니까?
내 배포 스크립트는 아카이브를 푸시하고 서비스를 다시 시작하지 않습니다. 배포의 각 단계에서 많은 색상으로 구분 된 정보를 인쇄하고 마지막에 이벤트 요약을 제공합니다. 프로세스가 실행 중이고 홈페이지가 200 상태 코드를 제공하고 있으며 모든 시스템과 서비스가 서로를 잘 볼 수 있음을 알려줍니다. 그런 다음 로그 파일, 4xx 및 5xx 수준 오류 및 주요 사이트 메트릭을 모니터링하는 스크립트의 일부가 아닌 별도의 서비스가 있습니다. 그런 다음 급격한 부정적인 영향이 발생할 경우 가능한 모든 매체 (이메일, txt 메시지 및 경보)를 통해 나에게 소리를 지 릅니다.
테스트를 실행하는 CI 서버와 CI 서버 사이에서 나는이 자동화 수준에서 말 그대로 배포하고 잊어 버렸습니다. 현재 프로세스의 안정성으로 인해 푸시 후 사이트에서 단일 페이지를 탐색하지 않아도되므로 원하는만큼 자주 배포 할 수있을뿐만 아니라 프로젝트의 새로운 개발자가 라이브로 업데이트 할 수 있습니다 탑승 후 몇 분 안에 사이트를 방문하십시오. 과거에는 모든 것을 전달하는 마스터 / 트렁크 지점에 커밋 한 후 CI 서버가 프로덕션에 자동 배포되도록했습니다. 그것이 내가 도구에 대해 얼마나 확신하는지입니다.
당신도 그래야합니다.
답변
또한 원격 디버깅으로 프로덕션 시스템을 실행하고 수동으로 단계별로 진행합니까? 적절한 스크립트 작성은 프로그램 작성과 동일합니다. 가지고있는 모든 문제는보고 확인해야 할 사항을 나타냅니다.
문제가 발생하면 적절한 롤백 절차를 거쳐 메시지를 보내야합니다. 발생하는 모든 것은 나중에 기록 될 수 있습니다. 스크립트의 버전을 제어하고 테스트 사례를 설정할 수 있습니다.
그러나 수동으로 명령을 실행하는 경우 이러한 이점이 없습니다. 대신 단점 목록이 있습니다.
- 당신은 좋은 로그가 없습니다, 쉘 기록은 계산되지 않습니다
- 아무도 그것을하는 방법을 모른다
- 단계가 빠짐
- 점검은 때때로 이루어집니다
- 배포 할 일부 항목이 누락 될 수 있습니다.
- 시간이 더 많이 걸립니다
- 프로세스 중에 방해받을 수 있습니다
쉘에 모든 것을 입력 한 경우 적절한 스크립트는 거의 동일해야합니다. 이것이 우리가 bash 스크립트를 사용하는 이유 중 하나입니다. 당신이하는 일을 신뢰한다면 왜 모든 것을 기록하고 강화할 수 없습니까? 컴퓨터가 확인하기 때문에 더 나은 확인, 더 빠른 확인, 더 많은 확인이 발생할 수 있습니다.
답변
나는 자극적 인 환경에서 뭔가 새로운 것을 시도하는 것이 약간 긴장하는 것을 이해할 수 있습니다. 잠재적 인 재난에주의하는 것은 Good Thing TM 입니다.
자동화 된 스크립팅도 Good Thing TM 이며 신중하게 접근하는 한 위험을 최소화하고 두려움을 줄일 수 있어야합니다. 제 충고는 이것입니다.
- 검사 목록 / 테스트 세트를 준비 (및 통합 환경에서 실습)하여 작동 여부와 문제가 무엇인지 신속하게 확인할 수 있습니다. 자세한 로깅이 도움이 될 수 있습니다.
- 모든 것을 백업하십시오. 잘못 작동하는 경우 복구 할 수 있도록 수동 롤백을 준비하고 연습하십시오.
- 실제 제품을 만들기 전에 최대한 많이 테스트하십시오. 통합 환경과 함께 좋은 방법 인 것 같습니다.
- 처음 시도 할 때 낮은 프로파일, 낮은 충격 변화에서 시도하십시오. 사소한 업그레이드 또는 패치와 같은 것. 아이디어는 잘못되면 낙진을 최소화하는 것입니다. 첫 달리기를 위해 높은 프로파일의 주요 업그레이드 (CEO 및 모든 경쟁 업체가보고있는 위치)를 선택하지 마십시오.
벨트 아래 몇 번의 성공적인 실행이 이루어지면 자신감이 커지고 곧 수동 배포를 어떻게 관리했는지 궁금해 할 것입니다.
답변
프로덕션 환경에 수동 배포에 대한 가장 큰 논거는 다음과 같습니다. 사용자는 사람이며 실수를 저지를 것입니다. 의심 할 여지없이 슬픔을 일으킬만한 일을 잊어 버릴 때가있을 것입니다. 잘 작성된 자동 배포는 같은 경향이 없습니다. 여전히 엉망인 프로덕션 배포가 가능하다는 것은 사실이지만 자동화 된 배포에는 해결해야 할 버그가 있기 때문입니다.
내 경험상 프로덕션에 대한 자동 배포의 이점은 엄청납니다. 가장 큰 문제는 주말에 협력하지 않는 수동 배포 프로세스를 진행하는 대신 재미있게 놀 수 있다는 것입니다.
프로덕션 배포를 자동화하기위한 몇 가지 주요 사항은 다음과 같습니다.
- 한 번에하지 마십시오! 자동 배포 작성을 천천히 시작하십시오. 먼저 별도의 비 프로덕션 환경을 설정하고 배포 자동화를 시도하십시오. 자동화 된 배포에 대한 신뢰를 쌓고 나면 프로덕션 배포에 대한 생각을 시작할 수 있습니다
- 릴리스 및 배포를 매우 자주 시작하십시오! 릴리스 대기중인 4 개월 코드가없는 경우 자동 배포를 훨씬 쉽게 수행 할 수 있습니다. 작은 기능과 버그 수정을 일주일에 여러 번 릴리스하십시오. 이 릴리스 스타일의 장점은 과소 평가 될 수 없습니다!
- 자동화 된 테스트를 통해 프로덕션 환경이 제대로 작동 할 것이라는 확신을 가지십시오. 다시 말하지만, 이것은 구축하는 데 시간이 걸리지 만 매우 중요합니다. 자동화 된 테스트는 항상 수동 승인 테스트보다 낫습니다. 물론 수동 수락 테스트는 괜찮지 만 자동화 된 테스트를 통해 프로덕션 환경에 배포해야하는지 여부를 알 수 있습니다. 이 자동화 된 지속적인 전달의 전체 프로세스를 가능하게하는 열쇠입니다. 테스트에 통과하지 못하면 프로덕션 환경에 배포하지 않는 것입니다.
답변
라이브 서버에서 스크립트를 실행하십시오. 작동하고 몇 번 잘 작동하면 완벽하게 확신합니다.
그러나 배포 스크립트보다 실수를 범할 가능성이 높습니다.