Serve kullanan ve Git kullanılarak sürüm kontrollü bir projem var . Serve, outputHeroku'ya dağıtmak istediğim statik dosyalar içeren bir klasör oluşturur .

Heroku Sedir yığını bundan pek hoşlanmadığı için Serve projesinin kendisini dağıtmak istemiyorum, ancak en önemlisi Heroku'nun statik web siteleri için harika desteğinden yararlanmak istiyorum.

Git uzaktan kumandasına bir alt klasör dağıtmanın bir yolu var mı? outputKlasörde (kulağa yanlış geliyor) bir Git deposu oluşturmalı ve bunu Heroku'ya göndermeli miyim?

Git-subtree ile daha da kolay bir yol var . Klasörünüzün 'çıktısını' Heroku'ya kök olarak göndermek istediğinizi varsayarsak, şunları yapabilirsiniz:

git subtree push --prefix output heroku master

Görünüşe göre şu anda git-subtree git-core'a dahil ediliyor, ancak bu git-core sürümünün henüz piyasaya sürülüp sürülmediğini bilmiyorum.

John Berryman'ın söyledikleriyle başladım, ama aslında heroku git tarihini hiç umursamıyorsanız daha basit olabilir.

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

Sanırım resmi git subtreeen iyi cevap, ancak mac'umda alt ağacın çalışması için sorun yaşadım .

Benzer bir sorun yaşadım. Benim durumumda, heroku deposundaki her şeyi havaya uçurmak ve alt dizinimdeki her şeyi değiştirmek hiçbir zaman sorun olmadı. Eğer durum buysa, aşağıdaki bash betiğini kullanabilirsiniz. Bunu Rails uygulama dizininize koymanız yeterlidir.

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

Eminim bunu geliştirmenin birçok yolu vardır - bu yüzden bana nasıl yapılacağını söylemekten çekinmeyin!

Uzun ve zor bir aydan sonra farklı şeyler denedikten ve her fark ettiğimde ısırıldıktan sonra,

Heroku, bir dağıtım mekanizması olarak bir git deposu kullandığından, onu bir git deposu olarak değerlendirmemelisiniz

rsync de olabilirdi, git için gittiler, bu yüzden dikkatiniz dağılmasın

eğer bunu yaparsanız, kendinizi her türlü incitmeye açarsınız. Yukarıda belirtilen çözümlerin tümü bir yerlerde sefil bir şekilde başarısız oluyor:

1. her seferinde veya periyodik olarak veya beklenmedik şeyler olduğunda bir şeyin yapılmasını gerektirir (alt modülleri itmek, alt ağaçları senkronize etmek, ...)
2. Örneğin, kodunuzu modüler hale getirmek için bir motor kullanırsanız, Bundler sizi canlı canlı yer, bunun için iyi bir çözüm bulma arayışı sırasında o projeyle yaşadığım hayal kırıklığının miktarını açıklamak imkansızdır.
   • motoru git repo bağlantısı olarak eklemeye çalışıyorsunuz + bundle deploy- başarısız, her seferinde güncellemeyi paketlemeniz gerekiyor
   • motoru :path+ bundle deploy- fail olarak eklemeye çalışırsanız , geliştirme ekibi :pathseçeneği "bu mücevher seçeneğiyle Bundler'ı kullanmıyorsunuz" olarak değerlendirir , bu nedenle üretim için paketlenmez
   • ayrıca, motorun her yenilemesi ray yığınınızı güncellemek ister -_-
3. Bulduğum tek çözüm, motoru /vendorgeliştirmede bir sembolik bağlantı olarak kullanmak ve aslında dosyaları üretim için kopyalamak.

Çözüm

Söz konusu uygulamanın git kökünde 4 projesi var:

1. api - profile bağlı olarak 2 farklı heroku sunucusunda çalışır - yükleme ve api
2. web - web sitesi
3. web-old - eski web sitesi, hala göç ediyor
4. ortak - bir motorda çıkarılan ortak bileşenler

Tüm projelerde motorun vendor/commonköküne bakan bir sembolik bağ vardır common. Heroku'ya dağıtım için kaynak kodunu derlerken, sembolik bağlantıyı kaldırmamız ve kodunu fiziksel olarak her ayrı ana bilgisayarın satıcı klasöründe olacak şekilde yeniden senkronize etmemiz gerekir.

1. ana bilgisayar adlarının bir listesini bağımsız değişken olarak kabul eder
2. geliştirme deponuzda bir git push çalıştırır ve ardından ayrı bir klasörde temiz bir git pull çalıştırır, böylece hiçbir kirli (beklenmeyen) değişikliklerin ana bilgisayarlara otomatik olarak gönderilmemesini sağlar
3. ana bilgisayarları paralel olarak dağıtır - her heroku git repo çekilir, yeni kod doğru yerlere yeniden senkronize edilir, git commit yorumundaki temel push bilgileriyle birleştirilir,
4. sonunda, hobi sahiplerine uyanmalarını ve her şeyin şarap olup olmadığını görmek için günlükleri takip etmelerini söylemek için curl ile bir ping gönderiyoruz
5. jenkins ile de iyi oynuyor: D (başarılı testlerden sonra sunucuları test etmek için otomatik kod itme)

En az (hayır?) Sorunla vahşi doğada çok çok güzel çalışıyor 6 aydır

İşte komut dosyası https://gist.github.com/bbozo/fafa2bbbf8c7b12d923f

Güncelleme 1

@AdamBuczynski, asla bu kadar basit değildir.

Birincisi, her zaman en azından bir üretim ve test ortamına sahip olacaksınız - ve daha kötüsü bir grup işleve özel kümeye sahip olacaksınız - aniden 1 klasörün n heroku projesine eşlenmesi gerekiyor ve oldukça temel bir gereksinim ve her şeyin bir şekilde organize edilmesi gerekiyor. komut dosyası, hangi kaynağı nereye dağıtmak istediğinizi "bilir",

sync_commonİkincisi, projeler arasında kod paylaşmak isteyeceksiniz - şimdi bölüm geliyor, geliştirmede sembolik bağlara sahip shennaniganların yerini Heroku'da gerçek eşzamanlı kod alıyor çünkü Heroku belirli bir klasör yapısı ve paketleyici ve rubygemler gerçekten gerçekten işleri çirkin hale getiriyorsa ortak konuları bir mücevherin içine çıkarmak istiyorum

Üçüncüsü, CI'yi takmak isteyeceksiniz ve bu, alt klasörlerin ve git repo'nun nasıl organize edilmesi gerektiğini biraz değiştirecek, sonunda, yukarıda bahsedilen özü elde edeceğiniz en basit olası kullanım durumunda.

Diğer projelerde Java sürümlerini eklemem gerekiyor, yazılımı birden fazla istemciye satarken, kurulum gereksinimlerine ve ne olmadığına bağlı olarak yüklenen modülleri filtrelemeniz gerekecek,

Bir şeyleri Rakefile veya başka bir şeye toplamayı gerçekten düşünmeliyim ve her şeyi bu şekilde yapmalıyım ...