자, 개발 모드에서 충분히 개발된 플러그인이 이미 있는 경우, 제3자 서비스에 의존하지 않고 해당 플러그인을 프로덕션 환경으로 옮기는 방법은 무엇인가요? 그런 방법이 실제로 존재하나요?
네, 이 문서에서 설명되어 있습니다.
진짜예요? 그 튜토리얼 전체가 GitHub에 의존하는데, 제 질문은 제3자에 의존하지 않는 방법에 대한 건데요.
GitHub 또는 GitLab에 호스팅하고, 평소처럼 클론을 생성하세요.
Discourse 자체는 Github, Docker Hub, Rubygems, NPM 레지스트리, LetsEncrypt 등 외부 서비스에 꽤 많이 의존하고 있습니다. 제 생각에 Github에 대한 플러그인 배포 독립성만 확보하는 것은 큰 의미가 없습니다.
아 맞아요, 그 부분을 놓쳤네요. 
그렇게 하는 것이 합리적입니다. 저는 작은 일을 처리하는 수많은 소형 플러그인을 개발했는데, 이런 플러그인들은 업데이트가 필요하지 않습니다. 그런데 GitHub을 관리하면서 이런 작은 플러그인을 올리는 것은 과한 조치일 뿐 아니라, 너무 많은 노력이 듭니다.
플러그인을 GitHub에 올리는 데는 1분도 걸리지 않습니다. 저장소를 생성하고, 생성 시 출력되는 셸 스크립트를 복사/붙여넣기만 하면 됩니다. 이 스크립트는 git init, git add, git push를 수행합니다. 이것이 바로 여러분이 이 질문을 처음 한 이유입니다. 플러그인의 크기가 아무리 작더라도 버전 관리 하에 두는 것은 좋은 생각입니다.
설치 스크립트를 복사하여 수정함으로써 플러그인 디렉토리를 Docker 이미지로 직접 복사하도록 만들 수도 있습니다. 이는 이미 로컬에 플러그인 코드가 있다고 가정합니다. 하지만 수정된 설치 스크립트를 업데이트에 맞춰 유지보수하는 작업은 10배 더 많은 노력이 필요할 것으로 예상됩니다.
내가 처음 물어보는 사람은 아니다(이전에 다른 사람들도 물어본 적 있다) 하지만 토론은 점점 더 복잡해지고 있고, 결국 너희들은 아무것도 답변하지 않는다.
유연성을 허용하지 않는 이 방식에 대한 정당성은 없다. 적어도 WordPress나 다른 서비스를 한 번만 사용해 보라. 플러그인 설치가 Discourse에서처럼 악몽이 아니라는 것을 알게 될 것이다.
GitHub를 사용하는 것은 괜찮지만, 로컬에서 작업하고 싶어하는 것이 비추천되는 건가?
명확히 말씀드리자면: 저는 Discourse.org에서 일하지 않습니다. 저도 여러분과 마찬가지로 그냥 사용자일 뿐입니다.
Communique에서 우리는 플러그인의 쉬운 설치/제거를 허용하는 자체 제어판을 개발했습니다. 재미있는 사실은: 그것은 Github를 대체하지 않으며, 그 위에 구축되어 있습니다.
만약 여러분이 WordPress 플러그인을 설치한 것이 아니라 개발해 본 적이 있다면, 그 말을 하지 않았을 것입니다. 왜냐하면 지금 그것이 악몽이기 때문입니다.
적절한 소스 컨트롤을 사용하면 나중에 발생할 수 있는 많은 문제와 번거로움을 예방할 수 있습니다. 플러그인의 미래를 안전하게 지키고, 업데이트에 대한 감사 이력을 추적하는 데 도움이 됩니다.
이것은 관심사를 모듈별로 분리하여 복잡성을 줄이는 방식을 제공합니다.
인스턴스를 독립적으로 관리할 수 있게 해주며, 서버 마이그레이션과 재구성을 훨씬 쉽게 만들어 줍니다.
또한 전문적인 접근 방식이기도 합니다.
깃허브(GitHub)나 기타 유사한 저장소 서비스를 사용하지 않고 어떻게 “완성된” 플러그인을 구축하고 테스트했는지 궁금합니다. 디스코urs(Discourse)를 위해 "작은 플러그인 여러 개"를 개발한 과정은 어땠나요?
도움을 주려는 사람들에게 대립적으로 나오면 좋은 결과를 얻기 어렵습니다. 말씀하신 것처럼 이전에 플러그인을 개발해 본 경험이 있다면, 디스코urs에 플러그인을 설치하는 것이 악몽 같은 일이 아니라는 것을 알 것입니다. 저장소를 사용하고 app.yml 파일을 편집하는 작업은 자체 호스팅을 하며 플러그인 개발에 익숙한 사람에게 쉬운 일이어야 합니다.
Codeberg 호스팅이 Discourse 플러그인에서 제대로 작동할지 모르겠습니다. 만약 작동한다면, 그것은 아마도 OP(첫 번째 게시자)가 원하는 것이겠죠.
GitHub 사용에 대한 의문을 제기하는 데 동의합니다. GitHub는 사전 통보 없이 약 300,000개의 저장소(DMCA 관련)를 삭제했으며, CMU 연구의 방법론 — 이전에 관찰되었던 저장소가 나중에 삭제되었는지를 확인하는 것 — 은 내부 집행(internal enforcement)을 통해 훨씬 더 많은 저장소가 삭제되었음을 시사합니다.
CMU 연구만으로도 가짜 스타(fake-star) 정리 작업에서 약 14,000개의 저장소가 삭제된 것으로 나타났으며, 이는 DMCA를 통해 매년 약 20,000~47,000개가 삭제되는 것과 비교됩니다. 해당 저장소들은 404 에러만 표시하기 때문에 전체적인 지표는 존재하지 않습니다.
즉, Discourse 플러그인에는 실질적인 위험이 없지만, 이제 Farble은 국가 안보 문제가 되었으며, 모든 사람이 Persona나 유사한 수단을 통해 KYC(고객 확인)를 받아야 하는 상황이 가까워질 경우 가까운 미래에 어떤 일이 일어날지 알 수 없었습니다.
그래서 Discourse 팀이 GitHub에서 벗어나라고 추천하는 건가요?
대안은 여러 가지가 있고, 그게 괜찮습니다. 원한다면 사용하셔도 되지만, 조금이라도 노력할 의사가 없다면 제 생각에는 Discourse를 실행하지 않는 게 나을 겁니다.
그게 싸우는 거라고 부르나요? 죄송하지만 아무도 싸우고 있지 않아요. 그냥 너무 예민하게 받아들이신 것 같네요. 그리고 그 말투가 싸우는 것처럼 들렸다면 죄송합니다.
어쨌든 질문에 답하자면, 당연히 일회용 GitHub 계정으로 했습니다. 그런데 그 프로젝트들이 너무 작아서 크게 테스트할 필요도 없고, 코드를 많이 쓸 필요도 없거든요.
이미 일회용 계정으로 설치해서 동작하는지 테스트는 해뒀습니다. 하지만 장기적으로 볼 때, 변경 사항을 넣고 싶을 때마다 저장소를 계속 지켜봐야 하는 건 원치 않아요. 정말로 작다는 건 장난이 아닙니다. 예를 들어 그중 하나는 홈 페이지에 외부 페이지 버튼 하나를 추가하는 것뿐이거든요.
차를 원한다고 말하면서 매년 차량 검사(차량 정기 검사)를 받는 것은 귀찮다고 하는 것과 같습니다.
공개 웹에서 호스팅을 운영할 때 발생하는 단순한 비용일 뿐입니다.
원하신다면 설치 스크립트를 수정하고 서버의 어딘가에서 심볼릭 링크를 설정하는 방법을 찾아낼 수 있을 것입니다. 하지만 아무런 작업도 하고 싶지 않은 것처럼 들리는데, 그렇게 하신다면 해당 솔루션을 작성하고 지원하는 일은 전적으로 당신에게 달려 있을 것입니다.
이를 테마 컴포넌트로 단순화할 수 있다면, 헤스 로빈슨(Heath Robinson)처럼 discourse_theme를 사용하여 로컬 머신에서 서버로 푸시할 수 있습니다. 하지만 로컬 머신이 고장 나거나 분실되거나 도난당하여 코드를 다시 가져올 수 없게 될 때(그때서야 서버에서 라이브 카피를 가져오는 방법을 찾아내야 하지만) 울지 마십시오.
discourse_theme gem을 설치하지 않으려는 경우, 주제는 zip 파일로 업로드할 수 있으며, 관리자 UI를 통해 직접 상당히 많은 기능을 구축할 수 있습니다.
다시 한번 강조하지만, Ruby로 작업하지 않는다면 플러그인이 전혀 필요하지 않으므로, 주제가 바로 당신이 찾고 있는 것일 가능성이 높습니다… git도 필요하지 않습니다.
좋은 지적입니다! 다만 discourse_theme의 장점은 바로 해당 위치에서 즉시 업데이트가 이루어진다는 점입니다. 이렇게 하면 업데이트를 지퍼로 압축해서 다시 업로드할 필요 없이 변경 사항을 빠르게 확인해 볼 수 있습니다.
차 운전을 하고 싶지만 주유소에는 한 번도 가지 않는 것과 더 비슷해 보입니다. “그냥 맨손으로 휘발유를 퍼서 탱크에 넣을게” 
플러그인을 개발할 때 GitHub을 사용했다면, 설치를 위해 소스로 사용하는 것은 매우 간단한 일입니다. 업데이트된 플러그인 파일을 서버로 수동으로 전송하는 것보다 저장소에 변경 사항을 푸시하는 것이 훨씬 적은 노력을 요구합니다.
호스팅된 Discourse 설치 환경에서 플러그인을 배포하기 위해 설치 과정을 우회하려는 것처럼 들립니다.
Customization > Plugin 이나 Customization > Theme component 를 말씀하시는 건지 궁금합니다.
예를 들어, 홈 화면의 사용자 정의 버튼은 Customization > Theme component 로 구현할 수 있습니다. TC는 zip 파일로 구성할 수 있으며(완전한 TC 구조를 갖추는 것이 가장 좋은 방법일 수 있음), 또는 내부 사용을 통해 테마 컴포넌트 생성 시 코드를 입력하는 방식으로 직접 작성할 수도 있습니다.