Discourse 버전 관리에 tests-passed를 사용하는 것이 기본/권장 사항이라는 것을 알고 있습니다. 하지만 지금까지 저희 팀은 app.yml 파일에서 Discourse 버전을 명시적으로 지정해 왔습니다. 예를 들어 version: 2.7.0.beta1처럼요. 이렇게 하는 이유는 프로덕션 환경에 어떤 버전이 배포되는지를 명시적으로 통제하고 싶기 때문입니다.
그러나 이 토픽에서 확인한 바와 같이, 우리가 항상 해왔던 방식으로 버전을 지정하는 것을 막는 버그가 존재합니다. 이는 저희 포럼의 오토스케일링 방식 때문에 큰 문제가 됩니다. 예를 들어 현재 프로덕션에 2.7.0.beta1 버전이 배포되어 있다고 가정해 보겠습니다. 그런데 포럼에 트래픽이 갑자기 폭증하여 해당 트래픽을 처리하기 위해 새로운 인스턴스를 스피닝 업해야 하는 상황이 발생했다고 합시다. 만약 app.yml에 tests-passed가 설정되어 있고, 지난 프로덕션 업데이트 이후로 새로운 Discourse 릴리스가 있었다면, 시스템은 기존 인스턴스와 충돌하는 새로운 버전(2.7.0.beta2)의 인스턴스를 스피닝 업하게 됩니다. 그 결과 서로 다른 두 버전이 동시에 존재하게 되며, 데이터베이스 변경 사항이나 기타 호환성 문제로 인해 프로덕션이 올바르게 작동하지 않게 됩니다.
이 외에도 플러그인 호환성 문제나, 프로덕션에 배포하기 전에 스테이징 환경에서 모든 것을 철저히 테스트하고 싶은 일반적인 필요성 등, 이러한 방식의 자동 업데이트를 원치 않는 다른 이유들도 있습니다.
참고로, Discourse 버전을 지정할 수 있도록 이 해결책을 적용하려고 시도해 왔지만, 현재 2.7.0.beta3 버전에서는 실패하고 있습니다. 여기에서 볼 수 있는 것과 유사한 bundler 오류가 발생하며, 해당 사용자의 해결책이 tests-passed 사용으로 돌아가는 것이었음을 알고 있습니다.
따라서 제 질문은 다음과 같습니다. 저희의 오토스케일링 구성과 프로덕션에 배포할 Discourse 버전을 명시적으로 지정해야 하는 일반적인 필요성을 고려할 때, Discourse 버전 관리를 효과적으로 통제하는 방법은 무엇일까요? 이러한 상황에서 다른 분들이 어떻게 대응해 왔는지 의견을 듣고 싶습니다.