라이브 웹 사이트의 배포 버그 수를 줄이려면 어떻게해야합니까?

많은 분들이이 문제를 경험 하셨을 것입니다. 웹 사이트 또는 웹 응용 프로그램이 실행 중이며 실행 중입니다. 다음 버전을 업로드하고 싶지만 구성 파일에서 값을 false로 설정하고 데이터베이스에 다른 레코드를 삽입하고 때로는 20 개 이상의 매개 변수로 계산 될 수있는 많은 사소한 작업을 수행하는 것과 같은 모든 것을 파악하지 못했습니다.

새 버전을 업로드하자마자 모든 것이 깨집니다. 이제 문제를 해결하는 데 최대 20 분이 소요될 수 있지만 허용하는 전반적인 스트레스와 회사에 대한 재정적 및 영업권 손해를 잊을 수없는 경우가 있습니다.

새 버전 배포의 초기 구성에서 발생하는 이러한 유형의 버그를 줄이는 방법은 무엇입니까?

추신 : 체크리스트는 언급하지 마십시오. 이미 체크리스트가 있습니다. 체크리스트의 문제점은 항상 업데이트되어야하지만 업데이트되지 않는다는 것입니다.

두가지:

• 배포를 테스트하는 실제 환경과 유사한 준비 환경
• 배포 후이 환경에 대한 충분한 테스트 자동화 및 자동화되지 않은.

할 수있는 다른 것들이 있습니다.

Troy Hunt의 자동 배포 에 대한 5 부 블로그 시리즈를 읽는 것이 좋습니다 . 그가 사용하는 툴링은 MS 스택에 따라 다르지만 개념은 보편적입니다.

업데이트 / 업그레이드 중에 문제를 해결하는 가장 중요한 방법 중 하나 인 Version control을 언급 한 사람이없는 이유가 궁금 합니다.

먼저, 배포는 저장소에있는 안정적인 지점의 복제본이어야합니다. 구성 파일, SQL 파일, 설치 / 업데이트 스크립트를 포함한 모든 것은 버전 제어되어야합니다.

둘째, 로컬 서버, 방금 생성 한 임시 가상 클라우드 서버, 매우 간단한 가상 호스트 설정 또는 본격적인 사용자 지정 응용 프로그램 등 "일부"준비 영역이 있어야합니다. 메인 앱과 함께 유지합니다. 이 "스테이징 영역"과 "개발 영역"의 차이점은 전자가 실제 배치 환경을보다 밀접하게 모델링 (또는 시뮬레이션)한다는 것입니다. 예를 들어 Apache 모듈을 사용하여 PHP 5.3.x에서 개발할 수 있지만 호스트가 FCGI를 사용하는 PHP 5.2.x이므로 준비 영역이 동일해야합니다.

그런 다음 먼저 개발 환경에서 업데이트를 작성하고 테스트하십시오. 해당 변경 사항을 스테이징 영역 저장소에 병합하고 다시 테스트하십시오. 이 시점에서 배포에 맞게 구성을 변경할 수 있습니다. 버전이 제어되기 때문에 아무것도 손실되지 않으며 문제 발생시 언제든지 되돌릴 수 있습니다.

마지막으로 라이브 배포 복사본의 준비 영역 변경 내용을 병합합니다.

준비 영역의 복잡성은 앱의 복잡성과 범위를 반영해야합니다. 그러나 어쨌든 버전 관리는 필수 불가결합니다.

물론 버전 제어를 사용하지 않으면 (이 중 어느 것도 적용되지 않음) 로고로 데이터베이스를 작성하는 것만 큼 순진합니다.

제안 된대로 준비 시스템을 사용하십시오 . 이를 통해 실제 환경에서 변경 사항을 테스트 할 수 있습니다.

이것은 또 다른 요점을 나타냅니다. 테스터가 있습니다. 내가 작성한 내용을 테스트해도 다른 사람이 내 응용 프로그램을 테스트 할 때만 큼 버그가 발견되지 않습니다.

또 다른 것은 배포 프로세스를 자동화합니다 . ant 마이그레이션으로 db 마이그레이션을 수행하고, capistrano 등을 통해 svn에서 자동으로 최신 버전을 배포하십시오. 무언가를 배포 할 때 클릭보다 더 많은 작업을 수행 할 필요가 없으며 모든 것이 자동으로 수행됩니다. 특히 일부 구성 설정이 필요한 웹 사이트의 경우 배포에 필요한 수동 단계는 악몽이며 무언가 잘못 될 가능성이 있습니다.

절대적으로 긍정적이지 않은 것은 A와 B 시스템을 고려하고로드 밸런서를 사용하여 B를 업그레이드 및 테스트하는 동안 모든 요청을 A로 라우팅 한 다음 A를 업데이트하는 동안 모든 것을 B로 라우팅하십시오.

보너스 포인트의 경우 C를 추가하고 시스템이 지리적으로 분리되어 지진으로 인해 2 개가 동시에 지워지지 않도록하십시오.

많은 응용 프로그램에서 나는 이것이 과도하다는 것을 인정합니다.

또한 필요한 트랜잭션 관리를 복잡하게하지만 문제를 극복 할 수는 없습니다.

예, 모든 단계를 수행하는 테스트 또는 준비 환경이 필요하지만 별도의 환경에 대해 별도의 구성 파일을 유지해야합니다.

Environments
|_property_files
    |_ dev
        |_ com.bla.util
        |    |_ example.properties
        |_ com.bla.beans
        |    |_ someconfig.xml
    |_ test
        ....
    |_ production
        ....
|_database_updates
    |_ dev
        |_ insert_new_static_data.sql
        |_ ...

...

기본적으로 빌드 및 배포 스크립트에서 XML 파일과 같은 환경 특정 메타 데이터 파일을 가져 와서 패키지하기 전에 빌드 위치에서 대체하는 환경 속성을 사용합니다. 또한 배포 스크립트에서 데이터베이스 업데이트에서 SQL 파일을 찾아 해당 환경에 대해 구성된 데이터베이스에서 실행합니다.

사용자 정의 빌드 작업 으로이 작업을 수행 할 수는 있지만 실제로 JUnit 테스트를 사용 하여이 작업을 수행합니다. SQL 예외가 발생하면 테스트에 실패하여 배치에 실패합니다. 일반적으로 SQL 스크립트에는 지능이 있습니다. 필요한 데이터가 환경에 이미 존재하면 삽입 또는 업데이트를 건너 뜁니다.

또한 특정 환경에서 실행해야하는 배치 또는 셸 스크립트에 대한 비슷한 디렉토리가 있습니다.

귀하의 질문에있는 모든 것은 이것입니다 : 그들은 항상 업데이트되어야하지만, 그렇지 않습니다.

이러한 구성은 자동화 된 빌드 및 배포를 주도하므로 업데이트하지 않으면 빌드가 실패하고 관리자에게 전자 메일이 전송됩니다. 그런 다음 팀이 컴파일하는 코드를 체크인하는 것만 큼 특정 릴리스의 빌드 및 배포 구성을 유지 관리하는 것이 중요합니다. 위반하면 빌드가 중단됩니다.

요컨대, CI ( Continuous Integration ) 원칙을 더 많이 채택 하면 생산 릴리스의 고통을 제거하는 데 도움이됩니다.

1) 먼저 테스트 사이트에 배포하고 변경 사항을 테스트하십시오.

2) 구성 파일 (웹 구성 또는 이와 유사한)에 모든 구성이 있어야합니다. 그런 다음이 구성은 응용 프로그램에만 적용되며 덮어 쓰지 않아야합니다. 그런 다음 테스트와 다른 것을 변경하는 것을 잊지 않고 변경 사항을 검토합니다.

위의 훌륭한 제안 외에도 사전 프로덕션 환경을 갖추고 자동화 된 테스트를 사용하십시오.

코드베이스 의 복잡성 을 줄 입니다. 일반적으로 코드가 적을수록 버그가 적고 버그를 쉽게 찾을 수 있습니다. 이것이 리팩토링, 우려의 분리 등의 철학입니다.

코드베이스를 세그먼트 화하십시오 . 일반적인 접근 방법 중 하나는 다음과 같이 분리하는 것입니다.

• 느리게 변화하고 사이트 전체에서 공유되는 몇 가지 핵심 부품
• 더 빨리 변할 수 있지만 각각의 작은 부분에만 영향을 미치는 많은 잎 부분

이러한 코드 기반에 대한 이해를 통해 개발 및 테스트를 핵심 부분에 집중할 수 있습니다. 버그가 가장 큰 영향을 미치기 때문입니다.

잘 실행 된 릴리스는 계획 및 커뮤니케이션에 관한 것입니다. 따라서 릴리스를 수행하기 전에 다음 질문을 고려하십시오.

1. 릴리스에 시간이 얼마나 걸리며 릴리스가 진행되는 동안 사람들이 내 제품과 계속 인터페이스 할 수있는 위험이 있습니까? 시스템에 위험이있는 경우 시스템을 오프라인으로 전환하고 "현재 유지 보수중인 시스템"메시지를 대신 배치하십시오.

2. 릴리스에 대해 미리 알려야 할 고객이 있습니까? 릴리스가 진행되는 동안 가능한 서비스 중단 또는 성능 저하에 대해 알려 주어야합니까? 개인적으로 나는 항상 과도한 의사 소통의 측면에서 실수를하며 모든 고객에게 공개 블로그 또는 유사한 장소에서 예정된 릴리스 또는 유지 관리 기간을 알려줍니다 .

3. 석방이 엉망이 되려면 어떻게해야합니까? 예를 들어, 릴리스가 제대로 진행되지 않으면 오프라인 상태의 시간을 최소화하는 방식으로 시스템을 롤백하고 복원해야합니까? 그렇다면 릴리스 롤백 단계가 잘 문서화되어 있습니까? 또는 문제가 발생했을 때 문제를 해결하는 데 도움을 줄 수있는 적절한 사람이 전화를 걸거나 직접 연락해야합니다. 개인적으로 릴리스 계획에 접근하는 가장 좋은 방법은 릴리스에 문제가 있다고 가정하는 것입니다. 그런 식으로 나는이 문제들 중 일부를 미리 생각해 보도록 강요했다.

다음으로 릴리스를 실행할 때 원활하게 실행되도록하는 가장 좋은 방법 중 하나는 연습, 연습, 연습 및 진행 과정에서 발생하는 모든 것을 문서화하는 것입니다. 따라서 프로덕션에 새 코드를 배포하기 전에 먼저 안전하고 올바르게 샌드 박스 처리 된 스테이징 환경에 코드를 배포하십시오. 프로덕션 배포를 담당하는 사람에게 준비를위한 테스트 배포를 수행하십시오. 이것을 드레스 리허설을 고려하고 이것이 실제 인 것처럼 자신을 행동하십시오. 당신이하는 모든 단계를 문서화하십시오; 실행하는 모든 명령, 실행하는 모든 SQL 코드, 수정 한 파일 및 수정 한 방법 및 각 단계에 대해 프로 시저가 올바르게 실행되는지 확인하는 방법을 문서화하십시오. 어떤 종류의 문제가 발생하면이를 해결하기 위해 무엇을했는지 기록하십시오.

그런 다음 실습 배포가 완료되고 메모를 살펴보고 프로세스를 세분화하여 오류를 제거 할 수 있는지 확인하십시오. 그런 다음 다시 끝까지하십시오 . "이 머신에 로그인하고이 명령을 실행 한 다음 데이터베이스에 로그인하여이 SQL 명령을 실행 한 다음 ..."과 같은 간단한 지시 사항 시트를 따라 릴리스 실행이 일상이 될 때까지 계속 연습하십시오.

위에 나열된 것은 운영 또는 릴리스 관리 팀이 릴리스를 원활하게 실행하기 위해 수행 할 수있는 작업입니다. 그러나 엔지니어링은 릴리스에서 위험을 최소화하기 위해 무엇을 할 수 있습니까?

1. 릴리스를 작게 유지하십시오. 간단히 말해서, 릴리스에 포함 된 코드 변경 세트가 복잡할수록 릴리스가 더 위험 해집니다. 같은 기간 동안 적은 수의 대규모 릴리스보다는 많은 수의 소규모 릴리스를 계획하여 운영 팀에 유리한 입장을 취하십시오.

2. 테스트, 테스트, 테스트 QA 환경에서 코드를 테스트하지 말고 스테이징 환경을 사용하여 소프트웨어도 테스트하십시오. 종종 코드 자체와 관련이 없거나 거의없는 버그가 있지만 환경 자체의 구성 (또는 둘의 혼합)에 근본적인 원인이 있습니다. 이러한 문제를 찾으려면 프로덕션과 밀접하게 관련된 환경 (예 : 준비)에서 코드를 테스트해야합니다.

마지막으로, 때로는 가장 중요한 것은 일이 잘못되는 것을 막기 위해하는 것이 아니라 잘못 될 때 행동하는 방식입니다. 따라서 운영 투명성에 대해 회사 내 문화를 구축하는 것이 중요하다고 생각합니다. 앞으로 고객에게 문제를 숨기려고하지 마십시오. 운영팀이 현재 인식하고 해결하려는 문제가있는 경우 Twitter를 적극적으로 사용하여 고객에게 알리십시오 ( Lighthouse 는이 기능이 훌륭합니다!). 고객이 문제가 있는지 확인할 수있는 서비스에 대한 "상태"페이지 게시를 고려하십시오 ( TypePad가 이에 대한 좋은 예를 제공함). 결론은 항상 과도한 통신 측면에서 잘못되었습니다. 당신의 고객은 그것에 대해 감사합니다.

여기에 많은 답변이 이미 문제에 대한 특정 솔루션을 구현하는 방법을 알려 주지만 실제 문제는 웹 사이트를 올바르게 마이그레이션 / 업데이트하는 것이 아닙니다. 그 뒤에있는 디자인 / 아키텍처는 취약 할 수 있습니다.

이것이 사실이라면, 구성 설정이 변경되거나 올바르게 설정되지 않은 경우에도 제대로 기능을 계속할 수있을만큼 견고하고, 발생하면 정상적으로 성능이 저하되도록 시스템 아키텍처를 조정해야합니다. 이상적으로 새 데이터베이스 열이 필요한 방식으로 새 기능을 추가했거나 이전 기능을 변경 한 경우 열이 누락 된 경우에도 사이트가 작동합니다 (새 기능이 없거나 이전 기능의 성능이 저하 된 형식 일 수 있음). . 고객은 돈을 잃지 말아야합니다. 최악의 경우, 고객이 개선 한 것에서 새로운 돈을받지 못할 수도 있습니다.

시스템이 취약하여 구성 설정으로 인해 심각한 문제가 발생할 수있는 경우 프로그램 업데이트가 문제의 유일한 원인이되지는 않으며 업데이트를 안전하게 수행하는 방법을 알아 내면 오류 발생시 발생할 수있는 피해 만 증가시킵니다. 다른 출처.