git repo의 하위 디렉토리 만 Heroku에 배포 / 푸시하는 방법은 무엇입니까?
Serve 를 사용 하고 Git을 사용하여 버전을 제어 하는 프로젝트가 있습니다. Serve는 output
Heroku에 배포하려는 정적 파일이 있는 폴더를 만듭니다 .
Heroku Cedar 스택이 너무 좋아 보이지 않기 때문에 Serve 프로젝트 자체를 배포하고 싶지 않지만 가장 중요한 것은 정적 웹 사이트에 대한 Heroku의 큰 지원을 활용하고 싶습니다.
하위 폴더를 git remote에 배포하는 방법이 있습니까? output
폴더에 Git 저장소를 생성하고 (잘못된 소리로) Heroku로 푸시해야합니까?
git-subtree 를 통해 훨씬 쉬운 방법 이 있습니다 . 폴더 'output'을 Heroku의 루트로 폴더를 푸시한다고 가정하면 다음을 수행 할 수 있습니다.
git subtree push --prefix output heroku master
현재 git-subtree가 git-core에 포함되어 있지만 해당 버전의 git-core가 아직 릴리스되었는지는 알 수 없습니다.
나는 비슷한 문제가 있었다. 필자의 경우 heroku 저장소의 모든 것을 날려 버리고 하위 디렉토리에있는 것으로 대체하는 것은 결코 문제가되지 않았습니다. 이 경우 다음 bash 스크립트를 사용할 수 있습니다. Rails 앱 디렉토리에 넣으십시오.
#!/bin/bash
#change to whichever directory this lives in
cd "$( dirname "$0" )"
#create new git repository and add everything
git init
git add .
git commit -m"init"
git remote add heroku git@heroku.com:young-rain-5086.git
#pull heroku but then checkback out our current local master and mark everything as merged
git pull heroku master
git checkout --ours .
git add -u
git commit -m"merged"
#push back to heroku, open web browser, and remove git repository
git push heroku master
heroku open
rm -fr .git
#go back to wherever we started.
cd -
이 문제를 개선 할 수있는 방법이 많이 있다고 확신합니다. 방법을 말씀해주십시오.
John Berryman이 시작한 것으로 시작했지만 실제로 heroku git history에 관심이 없다면 더 간단 할 수 있습니다.
cd bin
git init
git add .
git commit -m"deploy"
git push git@heroku.com:your-project-name.git -f
rm -fr .git
공식 git subtree
이 가장 좋은 대답 이라고 생각 하지만 하위 트리를 내 Mac에서 작동시키는 데 문제가있었습니다.
여러 가지 일을 시도하고 깨달을 때마다 물리는 길고 힘든 한 달 후에
Heroku가 git 리포지토리를 배포 메커니즘으로 사용하기 때문에 git 리포지토리로 취급해서는 안됩니다.
그것은 또한 rsync 일 수 있었으며, 그들은 자식으로 갔고, 이것 때문에 산만하지 않습니다.
그렇게하면 온갖 상처를 입을 수 있습니다. 위에서 언급 한 모든 솔루션이 어딘가에서 비참하게 실패합니다.
- 매번 또는 주기적으로 또는 예기치 않은 일이 발생할 수 있습니다 (하위 모듈 푸시, 하위 트리 동기화 등).
- 예를 들어 엔진을 사용하여 코드를 모듈화하면 번 들러가 당신을 살아있게 할 것입니다. 이에 대한 좋은 해결책을 찾기 위해 그 프로젝트에서 내가 겪었던 좌절의 정도를 설명하는 것은 불가능합니다
- git repo link +
bundle deploy
-실패 로 엔진을 추가하려고하면 매번 업데이트를 번들로 묶어야합니다. - 엔진을
:path
+bundle deploy
-실패 로 추가하려고 하면 개발자 팀은:path
옵션을 "이 gem 옵션과 함께 Bundler를 사용하지 않습니다"로 간주 하므로 프로덕션에 번들로 제공되지 않습니다 - 또한 엔진을 새로 고칠 때마다 레일 스택을 업데이트하려고합니다. -_-
- git repo link +
- 내가 찾은 유일한 해결책은 엔진을
/vendor
개발에서 심볼릭 링크 로 사용 하고 실제로 프로덕션 파일을 복사하는 것입니다.
해결책
문제의 응용 프로그램에는 git root에 4 개의 프로젝트가 있습니다.
- api-프로필에 따라 2 개의 다른 heroku 호스트에서 실행됩니다-업로드 및 api
- 웹-웹 사이트
- 웹 올드-이전 웹 사이트, 여전히 마이그레이션 중
- common-엔진에서 추출 된 공통 구성 요소
All of the projects have a vendor/common
symlink looking at the root of the common
engine. When compiling source code for deployment to heroku we need to remove the symlink and rsync it's code to physically be in the vendor folder of each separate host.
- accepts a list of hostnames as arguments
- runs a git push in your development repo and then runs a clean git pull in a separate folder, making sure no dirty (uncommited) changes are pushed to the hosts automatically
- deploys the hosts in parallel - every heroku git repo is pulled, new code is rsynced into the right places, commited with basic push information in the git commit comment,
- in the end, we send a ping with curl to tell the hobby hosts to wake up and tail the logs to see if all went wine
- plays nice with jenkins too :D (automatic code push to test servers after successful tests)
Works very very nice in the wild with minimal (no?) problems 6 months now
Here's the script https://gist.github.com/bbozo/fafa2bbbf8c7b12d923f
Update 1
@AdamBuczynski, it's never so straightforward.
1st you will always have a production and test environment at the least - and a bunch of function specific clusters at the worse - suddenly 1 folder needs to map to n heroku projects as a pretty basic requirement and it all needs to be organized somehow so that the script "knows" what source you want to deploy where,
2nd you will want to share code between projects - now comes the sync_common
part, the shennanigans with symlinks in development being replaced by actual rsynced code on Heroku because Heroku requires a certain folder structure and bundler and rubygems really really really make things ugly very badly if you want to extract the common threads into a gem
3rd you will want to plug in CI and it will change a bit how subfolders and git repo need to be organized, in the end in the simplest possible use case you end up with the aforementioned gist.
In other projects I need to plug in Java builds, when selling software to multiple clients you will need to filter modules that get installed depending on the installation requirements and whatnot,
I should really consider exploring bundling things into a Rakefile or something and do everything that way...
'IT story' 카테고리의 다른 글
Apple은 개인 API를 사용하고 있다는 것을 어떻게 알 수 있습니까? (0) | 2020.08.03 |
---|---|
Amazon 용 AWS_ACCESS_KEY_ID를 어떻게 얻습니까? (0) | 2020.08.03 |
각도로 요소 초점 설정 (0) | 2020.08.03 |
jquery는 자바 스크립트 라이브러리 또는 프레임 워크입니까? (0) | 2020.08.03 |
Groovy에서 문자열이 null이 아닌 공백인지 어떻게 알 수 있습니까? (0) | 2020.08.03 |