En iyi dağıtım stratejisi nedir?

82

Bir Magento mağazası kurmak, yalnızca kendiliğinden kurulabilen uzantılar geliştirmekle kalmaz, aynı zamanda son düzenleme özellikleri, kategoriler, ürünler, fiyat kuralları CMS sayfaları vb. Oluşturma gibi birçok "manuel giriş" işlemi gerektirir. Sistem Yapılandırmasında yapılan değişiklikler.

Bir Magento mağazasını geliştirme aşamasından aşamalandırma ve üretim ortamına yerleştirme konusunda en iyi stratejiyi ana hatlarıyla belirtmek için yardımınızı istiyorum.

Benim bir stratejim, yukarıda bahsi geçen varlıkları programlı olarak yaratan bir "dağıtım modülü" yazmaktır, ancak bu çok zaman alan bir iştir ve bazen bana biraz fazla önem vermez.

Geçenlerde, Yönetici görevlerini çoğaltmak için Selenium IDE kullanmaya başladım, ancak tüm test paketlerini kurmak için gereken süre yukarıda belirtilenlerden çok uzak değil.

Belki de en uygun çözüm, neyin konuşlandırılacağını seçmenize izin veren bir Magento Sisteminin anlık görüntüsünü yapabilen bir modülün kullanılması olabilir.

Yani:

dağıtım için stratejiniz nedir?
ne yapacağınızı seçmenize izin veren bir Magento Sisteminin anlık görüntüsünü yapabilen bir modül var mı?
eğer böyle bir modül mevcut değilse ve böyle bir modül makul bir çözüm ise, geliştirmesine katkıda bulunmak isteyen var mı?

Teşekkür ederim!

deploy admin entities

— Alessandro Ronchi
kaynak

Bu, başka bir etiket veya etiket kategorisine olan ihtiyacı gösterebilir. Bir kerelik bir dükkan mısınız yoksa bir hizmet sağlayıcı olarak genel öneriler mi arıyorsunuz? İkincisi, herhangi bir cevabın "müşterinin varlık verileri üzerinde ne kadar kontrol istediğine bağlı olduğuna" karar verilmelidir.

— puanlar

Benim bakış açım, dev bir takıma ait bir geliştiriciden biri. Farz edelim, çalışması için veri gerektiren bir bölüm geliştirdiğimi varsayalım, bir kategori yapısı söyleyin. Yapıyı Yönetici aracılığıyla oluşturuyorum, kodu yapıyorum ve kodumu zorluyorum. En iyi stratejinin aynı zamanda gerekli kategori yapısını oluşturan bir kod yazıp yazmak olduğunu merak ediyorum. Kategori yapım veya ayarlarım, kendi geliştiricilerini zorlayan diğer geliştiricilerinkilerle çakışırsa ne olur? Çakışmaları nasıl ele alabilirim? Bu benim amacım.

— Alessandro Ronchi

@AlessandroRonchi Bu çok yoğun bir nokta ve asla yaşanmaması gereken bir çatışma. Kategori yapınız anlamsız bir şekilde değişmesi gereken bir şey değildir, bu nedenle bir geliştirici yapısını, diğerlerini bilmeden yapınızda büyük bir değişiklik yapmamalı. Bu olursa, kişiler arası iletişiminizi ele almanız gerekir. Genel olarak, bir sitenin kategori yapısının ilk günden itibaren sabitlenmesi gerekir ve bir daha asla değiştirilmemesi gerekir. Değiştirmeniz gerekiyorsa, ilk defa doğru kapsamı girmediniz.

— ProxiBlue

@dedmeet ne yazık ki, tanıdığım ve çalıştığım dünyada her gün işler değişiyor; müşteriler fikrini değiştirir, geliştiriciler fikrini değiştirir, siyah kuğular meydana gelir. Değişime hazırlıklı olmalıyım; Yine de, kategori yapısının ilk günden itibaren değişmesi gerekmese bile, bu bölümün sadece küçük bir kısmıdır ve bütün bölüm, işleri halletmek için değiştirmesi gereken “devam eden bir çalışma” projesidir.

— Alessandro Ronchi

tamam, verilmiş, sürekli değişen bir ortamda çalışıyoruz, ancak hala bir kategori yapısı çatışması olmaması gerektiğine katılıyorum. Her birinin yapıyı değiştirdiği, sadece sorunlara yol açacağı ve dev zaman kaybına neden olacak birden fazla dal olmamalıdır. Neden dev b yapı değiştirirken farklı bir yapıya sahipken, b değişiyorsa, ikisi de işlerini zorluyorlar. Yapının değişmesi gerekiyorsa, projeye dahil olan tüm geliştiriciler, yeni yapının belirlenmesi sürecine dahil edilmelidir. Bunun ne zaman olabileceğini anlamama yardımcı olacak bir örnek verebilir misiniz?

— ProxiBlue

39

Benim düşüncem hepsini yazmaktır. İşlevsel olarak belirli bir modülle doğrudan ilgili olmayan herhangi bir şey için genellikle temel bir yapılandırma modülüne sahibim. (örneğin, özel URL oluşturma, önceki site URL'sini yeni site URL'sine yeniden yazar) ve bir modülle ilgili herhangi bir şeyi kendi yükleme komut dosyalarına ekleyin.

Bunun arkasındaki zihniyet, sitenin yeniden kurulması gerekiyorsa, taze bir db kullanarak, o zaman her şeyin olduğu gibi geri dönmesidir. Bu ayrıca, düzenli aralıklarla uat sitesini canlı db'nin bir kopyasıyla güncellememe yardımcı oluyor. Daha sonra, uat içindeki modüller tekrar konfigürasyonlarında yuva yaparken çalışmaya devam eder.

Posta ücretlerinde, alışveriş sepeti kurallarında vs. yapılan değişiklikler (temel olarak müşterilerin yönetici tarafından yönettiği şeyler) 'geçici veriler' olarak kabul edilir ve komut dosyası yazılmaz. Bu ürün verilerini içerir. Müşteri, seçeneğe sahiptir ve önce uat sitesinde yeni ithalatı test etmek için teşvik edilir.

Müşterilere nitelik oluşturmamaları, bunun yerine bir bilet talebi yoluyla yaratmaları söylenir. Bu daha sonra, müşterinin özellik için niyeti olduğuna dair bilgi toplamamı sağlıyor ve bazen daha iyi bir önerim var veya verilerin ne olduğundan emin olmak için hangi özelliklerin var olduğu konusunda daha iyi bir kod oluşturabilirim. temiz.

Evet komut dosyası daha uzun sürer, ancak tüm site yapılandırma ayarlarını daha sonra manuel olarak yeniden oluşturmak çok daha uzun sürer. Bir şeyi unutursanız ve sitenin düzgün çalışmamasına neden oluyorsanız veya bazı önemli yapılandırma ayarları olmayan yerel bir sitede yeni bir geliştirme çalışması yapıyorsanız, bu utanç verici olabilir.

— ProxiBlue
kaynak

1

Dedmeet ile aynı fikirdeyim. Tüm güncellemeleri nasıl yazacağınızı ilk öğrendiğinizde, daha ilk çalışma olabilir, ancak 3-4 geliştirici, evreleme, çalışma ve yaşam için yapılandırma güncellemelerini manuel olarak uygulamak zorunda kalırsanız, koordinasyon ve gerçek iş çok daha uzun sürecektir. İş akışımız oldukça benzer: Eğer yeniden kullanılabilir bir uzantı için yapılandırma gerekiyorsa, oraya koyun. Config müşteriye özelse, projeye özgü bir uzantıya yerleştirin. Birkaç istisnadan biri, güncellemesi / yaratması eğlenceli olmayan alışveriş sepeti kurallarıdır.

— Matthias Zeis

1

Sadece gerekli yapılandırma betiğini oluşturmaya yardımcı olan bir modülü serbest bırakıyorum, böylece kurulum betiğini manuel olarak oluşturma zorunluluğunu ortadan kaldırıyor. Modül, dışa aktarılacak yapılandırma değerlerinin seçilmesine izin vermek için core_config_data tablosunun ızgara ekranını kullanır. Hayatımı biraz daha basitleştir, umarım diğerleri için işe yarar. proxiblue.com.au/blog/magento-config-data-generator

— ProxiBlue

27

Birkaç ay önce bazı araştırmalar yaptım. İşte başvurabileceğiniz siteler.

~~Magento Temel URL'leri ve geliştirme / aşamalı kurulumlar~~
Magento Geliştirme ve Yerleştirme
Magento Git Kılavuzu ve İş Akışı
Dallanma için Magento MySQL Veritabanının Daha Hızlı Dökümü

— Oğuz Çelikdemir
kaynak

1

Teşekkürler, hepsini okuyacağım ve bazı düşünceler ile geri geleceğim.

— Alessandro Ronchi

Tüm kaynakları verdim; Bazılarını zaten biliyordum, tanımadığım diğerleri ise çok ilginç. Her neyse, hiçbiri benim sorunumun çözümü değil ve ihtiyaçlarımı yerine getirmeye çalışacak bir uzantı çizmeye karar verdim. Bana değerli tavsiyeler veren herkese teşekkür ederim. Buraya bazı sonuçlarla gelmeyi umuyorum.

— Alessandro Ronchi

Sevgili Alessandro, ben de daha rahat bir teknikte göründüğüm yolunu görmek istiyorum!

— Oğuz Çelikdemir

18

Hepinize teşekkür etmek istiyorum, çünkü düşünceleriniz beni farklı ortamlarda senkronize etme problemini çözme niyeti ile “Mageploy” adı verilen bir uzantı geliştirmeye teşvik etti.

http://www.mageploy.com

Mageploy hâlâ genişletilmiş, iyi belgelendirilmiş ve bazı avantajları olan birkaç projede kullanmış olsam bile tamamen test edilmiş olmalı.

Açık kaynaktır ve herhangi bir yardım veya öneri takdir edilecektir.

Saygılarımızla

— Alessandro Ronchi
kaynak

7

Komut dosyalarının kurulması ve varlıkların oluşturulmasıyla ilgili olarak, benim genel düşüncem, bir modül tarafından istenmesi ya da istenmesi durumunda, kurulum komut dosyasının bir parçası olarak oluşturulması gerektiğidir.

Son zamanlarda, dev / stage / prodüksiyon açısından, hazırlama sitesini, müşterinin birlikte çalışabileceği anlamına gelen veritabanının ana kopyası olarak kullanıyoruz. Geçmişte, muhtemelen karşılaştığımız en büyük sorun, özellikle ürün yükleme konusunda, müşteriyle içerik girişini koordine etmektir.

Anlık görüntünün işe yarayacağını nasıl düşündün? İdeal bir dünyada, belirli türlerdeki (ürünler, kategoriler, CMS vb.) İki veritabanı arasındaki farkı gösteren ve değişiklikleri birbiriyle birleştirmenize izin veren bir araca sahip olacağınızı düşünüyorum. söyledi.

— Paul
kaynak

1

"Betikleri yüklemek ve varlıklar oluşturmak konusunda genel düşüncem, bir modül tarafından istenmesi veya beklenmesi halinde, bir yükleme betiğinin bir parçası olarak oluşturulması gerektiğidir." Bu dikkate alınması gereken en belirgin nokta ve yapılandırma ayarları için de geçerli. Hızlı testim: Depoyu klonlamak ve çevreyi kurmak için yeni bir donanım gerektiğinde, sistemin çalışması için ne yapılması gerekiyor?

— puanlar

Yapılandırmada işbirliği yapmak için aşamalı bir siteyi istemcilerle paylaşmak teoride harika. Uygulamada, müşteriler zamanın% 99'unu değiştirdikleri her şeyi size söylemez, bu da bir şeyi batırmayı kolaylaştırır. Müşterilerin alışveriş sepeti kuralları, kategoriler, ürünler veya benzeri şeyler üzerinde çalışmasına izin verebiliriz, ancak yapılandırmaya müdahale etmelerine izin vermeyiz.

— Matthias Zeis

6

Bence nitelikleri, kategorileri, ürünleri, fiyat kurallarını yaratma ve düzenleme "dağıtım stratejisi" ile hiçbir ilgisi yoktur. Bütün bu öğeler bir mağaza için oldukça benzersizdir ve çoğu durumda, sizin için ürünlerin analizini ve araştırmalarını biraz talep eder. satacaklar.

Bahsettiğiniz tüm öğelerin benzer şekilde yapılandırılmış "tek beden herkese uyar" mağazaları oluşturuyorsanız, her mağaza için ihtiyacınız olan tüm ayarları yaptıktan sonra veritabanınızın "anlık görüntüsünü" dışa aktarabilirsiniz.

— Rutger
kaynak

Hayır, "tek beden herkese uyar" meselesi değil; geliştiriciler olarak kaynak kodumuzu geliştirme ekibinin başka bir üyesinden biriyle birleştirme zamanı geldiğinde aynı durum söz konusudur: bu durumda sihri yapan kaynak kontrol sistemlerimiz vardır. Benim sorum daha çok "dev" olmayan şeyleri yapılandırma ayarları ve tipik yönetici ayarları ve girişleri ile birleştirmekti.

— Alessandro Ronchi

Ah tamam, Bu daha netleştirir

— Rutger

Tamamıyla yeni bir web sitesi oluşturduğumuzu, eski verilerle hiç sorunum olmadığımızı diyelim. Hemen hemen her zaman geliştiricilerimiz için aynı veritabanını kullanıyoruz. Bu birçok sorunu çözer. Diğer durumlar için, bir tür yol haritasında / senaryoda gereken tüm adımları yazmaktan ve birleştirmeden sonra hepsini yeniden uygulamaktan (henüz) daha iyi bir çözümüm yok. "Magento çekirdeği" yönetici ayarlarından yalnızca bir kişi sorumluysa, bunlar pek çok adımda olmamalıdır. Bunu bir zamanlar buldum ama hiç denemedim tinybrick.com/magento-modules/admin-tools/…

— Rutger

2

İki mükemmel zaman kazandıran araç eklemek istiyorum:

Geliştirme için: Magicento eklentisi ile PhpStorm IDE
Dağıtım için: Magentify , Magento için bir Capistrano tarifi

— osondoar
kaynak

Bizi Magentify hakkında bilgilendirdiğiniz için teşekkür ederim, bilmiyordum ve deneyeceğim. Bununla birlikte benim odak noktam, bir kod tabanı yayınlamak anlamında konuşlandırmaktan ziyade, farklı geliştirme ortamını senkronize etmekten daha fazla. Mageploy, Magentify ile entegre olabilir, ancak farklı ortamlar arasında farklı olan belirli kimlik numaralarından bağımsız olarak veritabanı değişikliklerinin bir kısmını otomatik olarak hizalamak için kullanılan farklı bir araçtır. Saygılarımla, Alessandro

— Alessandro Ronchi