Tôi có một dự án sử dụng Serve và được kiểm soát phiên bản bằng Git. Serve tạo một outputthư mục với các tệp tĩnh mà tôi muốn triển khai cho Heroku.

Tôi không muốn tự triển khai dự án Serve vì ngăn xếp Heroku Cedar có vẻ không quá thích nó, nhưng quan trọng nhất là tôi muốn tận dụng sự hỗ trợ tuyệt vời của Heroku cho các trang web tĩnh.

Có cách nào để triển khai một thư mục con tới một điều khiển từ xa git không? Tôi có nên tạo một repo Git trong outputthư mục (nghe có vẻ sai) và đẩy nó lên Heroku?

Có một cách thậm chí còn dễ dàng hơn thông qua git-subtree . Giả sử bạn muốn đẩy 'đầu ra' thư mục của mình làm thư mục gốc sang Heroku, bạn có thể làm:

git subtree push --prefix output heroku master

Có vẻ như hiện tại git-subtree đang được đưa vào git-core, nhưng tôi không biết liệu phiên bản git-core đó đã được phát hành chưa.

Tôi bắt đầu với những gì John Berryman đưa ra, nhưng thực ra nó có thể đơn giản hơn nếu bạn không quan tâm chút nào đến lịch sử git của heroku.

cd bin
git init
git add .
git commit -m"deploy"
git push git@heroku.com:your-project-name.git -f
rm -fr .git

Tôi đoán chính thức git subtreelà câu trả lời tốt nhất, nhưng tôi đã gặp vấn đề khi đưa cây con hoạt động trên máy mac của mình.

Tôi đã có một vấn đề tương tự. Trong trường hợp của tôi, không bao giờ là vấn đề khi thổi bay mọi thứ trong kho lưu trữ heroku và thay thế nó bằng bất cứ thứ gì có trong thư mục con của tôi. Nếu đây là trường hợp của bạn, bạn có thể sử dụng tập lệnh bash sau. Chỉ cần đặt nó vào thư mục ứng dụng Rails của bạn.

#!/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 -

Tôi chắc rằng có rất nhiều cách để cải thiện vấn đề này - vì vậy hãy cho tôi biết cách thực hiện!

Sau một tháng dài vất vả thử nhiều thứ khác nhau và lần nào tôi cũng nhận ra,

chỉ vì Heroku sử dụng kho lưu trữ git làm cơ chế triển khai, bạn không nên coi nó như một kho lưu trữ git

nó cũng có thể là rsync, họ đã sử dụng git, đừng để bị phân tâm vì điều này

nếu bạn làm như vậy, bạn mở lòng mình với tất cả các loại tổn thương. Tất cả các giải pháp nói trên đều thất bại thảm hại ở đâu đó:

1. nó yêu cầu một cái gì đó phải được thực hiện mọi lúc, hoặc định kỳ, hoặc những điều không mong muốn xảy ra (đẩy mô-đun con, đồng bộ hóa cây con, ...)
2. nếu bạn sử dụng một công cụ chẳng hạn để mô-đun hóa mã của mình, Bundler sẽ ăn tươi nuốt sống bạn, thật không thể diễn tả được mức độ thất vọng mà tôi đã có với dự án đó trong quá trình tìm kiếm giải pháp tốt cho việc này
   • bạn cố gắng thêm công cụ dưới dạng liên kết git repo + bundle deploy- không thành công, bạn cần cập nhật gói mỗi lần
   • bạn cố gắng thêm công cụ dưới dạng :path+ bundle deploy- fail, nhóm nhà phát triển coi :pathtùy chọn là "bạn không sử dụng Bundler với tùy chọn gem này" nên nó sẽ không gói để sản xuất
   • ngoài ra, mỗi lần làm mới động cơ đều muốn cập nhật ngăn xếp đường ray của bạn -_-
3. giải pháp duy nhất tôi đã tìm thấy là sử dụng engine làm /vendorliên kết tượng trưng trong quá trình phát triển và thực sự sao chép các tệp để sản xuất

Giải pháp

Ứng dụng được đề cập có 4 dự án trong git root:

1. api - tùy theo hồ sơ sẽ chạy trên 2 host heroku khác nhau - upload và api
2. web - trang web
3. web-old - trang web cũ, vẫn đang di chuyển
4. chung - các thành phần phổ biến được trích xuất trong một động cơ

Tất cả các dự án đều có một vendor/commonliên kết biểu tượng nhìn vào gốc của commonđộng cơ. Khi biên dịch mã nguồn để triển khai cho heroku, chúng ta cần xóa liên kết tượng trưng và rsync, mã của nó để thực tế nằm trong thư mục nhà cung cấp của từng máy chủ riêng biệt.

1. chấp nhận danh sách tên máy chủ lưu trữ làm đối số
2. chạy một git push trong repo phát triển của bạn và sau đó chạy một git pull sạch trong một thư mục riêng biệt, đảm bảo rằng không có thay đổi bẩn (không giới hạn) nào được đẩy lên máy chủ tự động
3. triển khai song song các máy chủ - mọi repo git heroku đều được kéo, mã mới được nhập vào đúng vị trí, được cam kết với thông tin đẩy cơ bản trong nhận xét git commit,
4. cuối cùng, chúng tôi gửi một ping với curl để yêu cầu những người chủ sở thích thức dậy và kiểm tra các nhật ký để xem tất cả đã thành rượu chưa
5. chơi tốt với jenkins quá: D (tự động đẩy mã đến máy chủ thử nghiệm sau khi thử nghiệm thành công)

Hoạt động rất tốt trong môi trường hoang dã với các vấn đề tối thiểu (không?) 6 tháng nay

Đây là tập lệnh https://gist.github.com/bbozo/fafa2bbbf8c7b12d923f

Cập nhật 1

@AdamBuczynski, nó chưa bao giờ đơn giản như vậy.

Thứ nhất, bạn sẽ luôn có môi trường sản xuất và thử nghiệm ít nhất - và một loạt các cụm chức năng cụ thể thì tệ hơn - đột nhiên 1 thư mục cần ánh xạ đến n dự án heroku như một yêu cầu khá cơ bản và tất cả cần được tổ chức theo cách nào đó tập lệnh "biết" nguồn nào bạn muốn triển khai ở đâu,

Thứ hai, bạn sẽ muốn chia sẻ mã giữa các dự án - bây giờ đến sync_commonphần, các bí ẩn với các liên kết tượng trưng đang được phát triển được thay thế bằng mã rsynced thực tế trên Heroku vì Heroku yêu cầu một cấu trúc thư mục nhất định và gói và rubyge thực sự thực sự làm mọi thứ trở nên xấu đi rất nhiều nếu bạn muốn trích xuất các chuỗi chung thành một viên ngọc

Thứ 3, bạn sẽ muốn cắm CI và nó sẽ thay đổi một chút cách sắp xếp các thư mục con và git repo, cuối cùng trong trường hợp sử dụng đơn giản nhất có thể, bạn kết thúc với ý chính đã nói ở trên.

Trong các dự án khác, tôi cần cài đặt các bản dựng Java, khi bán phần mềm cho nhiều khách hàng, bạn sẽ cần lọc các mô-đun đã được cài đặt tùy thuộc vào yêu cầu cài đặt và không,

Tôi thực sự nên xem xét việc khám phá gói mọi thứ vào một Rakefile hoặc một cái gì đó và làm mọi thứ theo cách đó ...