'
```
---
### Author:  [@zsero](https://meta.discourse.org/u/zsero)
#### Post date: [12월 3, 2019, 5:20오후 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/9 "2019-12-03T17:20:01Z")
고맙습니다, 이제 완벽하게 작동합니다!
---
### Author:  [@hosna](https://meta.discourse.org/u/hosna)
#### Post date: [12월 3, 2019, 8:24오후 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/10 "2019-12-03T20:24:22Z")
이 문제가 새로운 업데이트와 관련이 있는 건가요?
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [12월 3, 2019, 9:15오후 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/11 "2019-12-03T21:15:03Z")
컨테이너를 다시 빌드해야 합니다.
```plaintext
cd /var/discourse
git pull
./launcher rebuild app
```
최신 변경 사항이 Discourse보다 먼저 업데이트되어 `Discourse.redis`를 찾지 못하므로 docker\_manager를 깨뜨린다고 확신합니다.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12월 3, 2019, 9:23오후 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/12 "2019-12-03T21:23:49Z")
> [@gerhard](#):
>
> 최신 변경 사항이 Discourse보다 먼저 업데이트되어 `Discourse.redis`를 찾지 못하므로 docker\_manager가 깨질 것이라고 꽤 확신합니다.
하지만 `git pull; ./launcher rebuild app`을 실행하면 문제가 해결되죠?
저는 [새로운 컨테이너 이미지가 릴리스될 때 업그레이드를 수행하는 클라이언트 목록](https://www.literatecomputing.com/automatic-rebuilds-when-they-are-needed/)을 가지고 있습니다. 보통 (1) 새로운 컨테이너가 필요하고 (2) 새로운 베타 버전이 릴리스된 직후에 해당 업그레이드를 수행합니다.
미래를 신뢰할 수 있게 예측하는 능력이 다소 제한적이라는 점은 알고 있지만, 곧 새로운 베타 버전이 릴리스될 것으로 예상합니까?
---
### Author:  [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)
#### Post date: [12월 5, 2019, 10:45오전 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/13 "2019-12-05T10:45:22Z")
오늘 또는 다음 주 초에 베타 버전을 출시할 예정입니다
---
### Author:  [@zsero](https://meta.discourse.org/u/zsero)
#### Post date: [12월 26, 2019, 12:44오전 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/14 "2019-12-26T00:44:50Z")
다시 고장이 났습니다. git pull + 재빌드 후 전체 로그:
[discourse.txt](https://meta.discourse.org/uploads/short-url/hk50Azqg3R5Txdjj2R5sH6Bsnam.txt) (24.4 KB)
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [12월 26, 2019, 2:00오전 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/15 "2019-12-26T02:00:53Z")
현재 “stable” 분기는 깨져 있습니다.
---
### Author:  [@zsero](https://meta.discourse.org/u/zsero)
#### Post date: [12월 26, 2019, 9:29오후 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/16 "2019-12-26T21:29:45Z")
간단한 요약: tests-passed로 해결했고, 1일간의 다운타임이 발생했습니다.
상세 내용: 저는 이 소프트웨어가 오늘날 인터넷에서 작성된 가장 높은 품질의 오픈소스 소프트웨어 중 하나라고 생각합니다. 견고한 비즈니스 모델과 훌륭한 팀을 갖추고 있죠. 그런데 왜 업그레이드 메커니즘이 이렇게나 깨져 있는 걸까요?
1. 앱 내 업그레이드 기능으로 인해 너무 많은 다운타임이 발생해, 아예 사용하지 않고 항상 재빌드(rebuild)를 하기로 결정했습니다.
2. 하지만 이 스레드에서 볼 수 있듯이, 최근 2번 중 2번 모두 재빌드도 매우 깨진 앱을 만들어냈습니다. 이는 제가 혼자서는 절대 해결할 수 없었던 상황이었고, 여기 추천받은 대로 "tests-passed"로 돌아가는 것 외에는 다른 방법이 없었습니다.
이렇게 잘 작성된 소프트웨어에서 업그레이드 메커니즘이 왜 이렇게나 깨져 있는 걸까요? 내장된 업그레이드 메커니즘으로 5년 이상 아무 문제 없이 돌아가는 워드프레스 사이트가 많은데, 왜 이런 일이 발생하는 걸까요?
재빌드는 항상 git 브랜치를 기반으로 이루어지고, 릴리스는 git과 전혀 관련이 없다면, Discourse에서 릴리스를 제공하는 의미가 무엇일까요?
제게는 릴리스란 git 태그나 zip 파일이어야 합니다. 왜 현대적인 패키지 매니저에서 할 수 있듯이 2.3.x 버전으로 재빌드를 할 수 없는 걸까요?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12월 26, 2019, 10:35오후 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/17 "2019-12-26T22:35:08Z")
결론적으로, `tests-passed`는 discourse.org가 서버에 배포하는 버전으로, `stable`보다 더 철저히 테스트되어 안정적입니다. `tests-passed`를 유지하면 문제가 덜 발생할 것입니다. `stable`을 실행하려면, 프로덕션 환경에서 업그레이드를 실행하기 전에 스테이징 서버를 통해 업그레이드를 테스트하는 등 `tests-passed`를 실행하는 것보다 더 많은 작업이 필요하다는 점을 이해해야 합니다.
---
### Author:  [@zsero](https://meta.discourse.org/u/zsero)
#### Post date: [12월 26, 2019, 11:05오후 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/18 "2019-12-26T23:05:59Z")
안정적이고 신뢰할 수 있는 것을 원합니다.
> `tests-passed`는 [discourse.org](http://discourse.org/)가 서버에 배포하는 버전으로, `stable`보다 테스트가 더 잘 되어 있고 더 안정적입니다.
이 버전을 계속 사용할 것입니다. 여전히 매우 이상한 점이 두 가지 있습니다:
- 실제로 안정적이라면 왜 `stable`이 아니라 `test-passed`라고 부르는 걸까요? "stable"은 일종의 "legacy"로 이름이 바뀌어야 합니다.
- 릴리스 시스템이 여전히 이해가 되지 않습니다. Git 브랜치에서 빌드하는 것이라면, 릴리스를 하는 목적은 무엇인가요? 예를 들어 2.4.x가 성숙할 때까지 2.3.x를 계속 사용하길 원하는데, Discourse의 모델에서는 이것이 전혀 불가능하다고 생각합니다.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [12월 26, 2019, 11:06오후 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/19 "2019-12-26T23:06:54Z")
> [@pfaffman](#):
>
> `stable`보다 테스트가 더 잘 되어 있고 더 안정적입니다. `tests-passed`를 유지하면 문제가 적을 것입니다. `stable`을 실행하려는 경우, 프로덕션 환경에서 업그레이드를 실행하기 전에 업그레이드를 테스트하기 위해 스테이징 서버를 실행하는 것처럼 `tests-passed`를 실행하는 것보다 더 많은 작업이 필요하다는 점을 이해해야 합니다.
정중히 말씀드리지만, 저는 이에 동의하지 않습니다. `stable`은 매우 안정적이고, 글자 그대로 '안정적’입니다. Rubygems가 의존성을 업데이트하면서 `tests-passed`와 `stable` _모두_가 깨졌고, 이를 해결하는 것은 [수정 사항](https://github.com/discourse/discourse/commit/b445e0e76a70c0b51a2e8223911f0ec9e09315a7)을 [백포트](https://github.com/discourse/discourse/commit/a6701d8710ea870a59cefdd3edc590261103029e)하는 것뿐이었습니다.
참고로, `gem update` 명령에서 rubygems를 특정 버전으로 고정(pinning)했다면 이를 피할 수 있었습니다. `gem update --system 3.0.6`을 사용했으면 안전했을 것입니다.
`stable`이 `tests-passed`보다 더 오래 깨져 있었다는 사실은 그저 우연이며, 제가 기억하는 바로는 처음 있는 일입니다.
> [@zsero](#):
>
> 예를 들어, 2.4.x가 성숙할 때까지 2.3.x를 유지하고 싶지만, Discourse의 모델로는 이것이 전혀 불가능하다고 생각합니다.
우리는 6년 넘게 수백 개의 Discourse 인스턴스에서 `stable`을 기본값으로 유지해 왔으며, 큰 문제 없이 운영해 왔습니다.
---
### Author:  [@zsero](https://meta.discourse.org/u/zsero)
#### Post date: [12월 26, 2019, 11:55오후 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/20 "2019-12-26T23:55:33Z")
이 스레드만 봐도 stable 버전이 rebuild 후 깨진 상태로 남아 있는 경우가 여러 번 있었으니, 처음 있는 일이 아닙니다. discourse.org의 상용 인스턴스가 test-passed 상태라면, 저는 그쪽에 맞춰 진행할 것입니다.
> 우리는 6년 넘게 수백 개의 Discourse 인스턴스에서 stable을 기본값으로 사용해 왔으며, 심각한 문제 없이 운영해 왔습니다.
stable을 고수하는 것과 2.3.x 버전을 고수하는 것은 매우 다른 개념입니다. 예를 들어 stable은 2.4.x가 충분히 성숙할 때까지 2.3.x에 머무르지 못하게 합니다. 또한 프로덕션 환경의 모든 구성 요소를 고려할 때, 저는 x.x.3 또는 x.x.4가 나올 때까지 업그레이드를 미루는 방식을 선호합니다. 현재로서는 이것이 불가능하다고 생각합니다.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [12월 27, 2019, 12:59오전 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/21 "2019-12-27T00:59:21Z")
> [@RGJ](#):
>
> 우리는 6년 넘게 수백 개의 Discourse 인스턴스에서 stable을 기본값으로 유지하며 이 방식을 사용해 왔고, 심각한 문제는 없었습니다.
그것이 사실이라는 것은 압니다. 하지만 당신은 평균적인 Discourse 관리자가 아니에요. 😉 당신은 저를 여러 번 구해 주셨고, 저는 원칙적으로 당신이 하시는 모든 말을 두 번씩 읽어서 기억할 수 있도록 하려고 하지만, 여전히 대부분의 일반 사용자에게는 tests-passed 버전을 유지하는 것이 가장 안전하다고 생각합니다.
> [@zsero](#):
>
> 예를 들어, 모든 것을 프로덕션 환경에 적용할 때, 저는 x.x.3 또는 x.x.4 버전이 나올 때까지 업그레이드를 하지 않는 것을 선호합니다. 저는 이것이 현재는 불가능하다고 생각합니다.
태그 대신 git 커밋 ID를 사용할 수 있습니다.
---
### Author:  [@zsero](https://meta.discourse.org/u/zsero)
#### Post date: [12월 27, 2019, 1:19오전 UTC](https://meta.discourse.org/t/latest-rebuild-broken/134962/22 "2019-12-27T01:19:47Z")
> [@pfaffman](#):
>
> tag 대신 git commit id를 사용할 수 있습니다.
하지만 그렇게 하더라도 stable 버전이 깨진 상황에서는 문제를 해결해 주지 못할 텐데요? 두 경우 모두 문제가 되었던 것은 누락된 백포트(backport)였고, 어떤 git commit id에서도 동일하게 누락될 것이라고 생각합니다.
따라서 Discourse에는 Wordpress처럼 zip 파일을 다운로드하거나 yarn/pip/gem 같은 패키지 매니저를 사용하여 설치하는 의미의 "릴리스(release)"라는 것이 존재하지 않습니다. 이는 Discourse가 외부 패키지의 라이브 버전을 항상 사용하여 "재빌드(rebuilt)"되기 때문이며, 정식 릴리스가 이루어지지 않기 때문입니다.
[다음 페이지](https://meta.discourse.org/t/latest-rebuild-broken/134962.md?page=2)