Bir web sitesinin sürüm kontrolü: dev / production ön uç dosyaları

Web sitesi projelerimizi kontrol etmenin daha iyi bir yolunu düşünmeye çalışıyorum. Unutmayın, sadece bir ön uç geliştiriciyim, bu yüzden derin bir VCS bilgim yok.

İş akışları değişiyor ve geçmiş sürüm kontrol alışkanlıkları artık kullanılmıyor. Ana sorun, her web sitesi için 2 ön uç dosya dizisi olmasıdır.

Geliştirme ortamı (daha az dosya, sıkıştırılmamış js, resimler vb.). İnşa ortamı, "yontulmuş" (her şey insanlar tarafından sıkıştırılmış ve okunamaz).

Ancak bir web sitesini kaynak dosyalarıyla satamazsınız. Pek de doğru değil.

2 depoya sahip olmanın çözümü vardır: bir derleme, bir dev, gulp dizini inşa etmek için dev dosyaları gönderir. Ama bunu korumak için bir güçlük, küçük şirketler ile bu kadar büyük olduğunu sanmıyorum. Çok sayıda depo oluşturur ve insanlar birkaç depo ile, bazen bir svn repo ile bile yönetmek zorunda kalırlar, sorunlar ortaya çıkar.

Yani 1 repo sahip olmanın çözümü de var: kaynak dosyalar ve aynı svn'deki prod dosyaları. Ancak, web sitesi yerel dev sunucusundan üretim sunucusuna gittiğinde kaynak dosyalarını kaldırmak gerekir (bu nedenle, konumu, geliştiricisi veya üretimine bağlı olarak tek bir depoda farklı dosyalar vardır). Duyduğum kadarıyla, bu iyi değil

Sürüm kontrol sistemi ile ilgili bir ön uç iş akışını yönetmenin doğru yolu nedir?

Kaynak kontrolünün temel bir kuralı , repoya (orijinal kaynak dosyaları) yalnızca elle yazılmış eserler koymanız gerektiğidir, "derlenebilir" veya "oluşturulabilen" her şeyin burada depolanması gerekmez, çünkü artıklık üretecektir . Bir olabilir (isteğe bağlı olarak) adım onları tam otomatik değildir, ya da yapı aşamaları yeniden oluşturmak için zaman, amaca önbelleğe alma için çıkış yavaş yeniden zaman, bir Repo (bazen de denir eserler) ara çıkışları / bir oluşturma işlemi parçalarını depolamak .

Bu nedenle, dev kaynak dosyalarınızdan üretim dosyalarını oluşturmak için tam otomatik bir işleminiz varsa, yalnızca dev dosyalarını kaynak denetimine koymanız gerekir (üretim dosyalarını oluşturmak için komut dosyalarıyla birlikte). Değilse, böyle bir süreç oluşturun. Kaynaktan oluşturulduktan sonra hiç kimsenin üretim dosyalarıyla elle uğraşmadığından emin olun. VCS'nizden "doğrudan" dağıtmak istiyorsanız, dev kaynak dosyalarını kaynak denetiminden çeken, "yutmayı" yapan ve ortaya çıkan dosyaları tek adımda üretime aktaran bir dağıtım komut dosyanız olduğundan emin olun.

Tabii ki, kaynak kontrolünü aynı zamanda "zayıf adamın yedeği" veya üretim dosyalarınız için bir önbellek olarak kullanmak istiyorsanız, bu amaçla ikinci bir repo kurabilir ve üretimden sonra üretim dosyası yapısının bir kopyasını koyabilirsiniz. Bu repo geliştirme için hizmet etmeyecek ve kurulduktan sonra, el ile sürdürmeniz gerekmemelidir. Bu nedenle , bu "prod repo" ya yedekleme yapmak için herhangi bir manuel adım olmayacağından emin olun - yedeklemeyi otomatik olarak yapan dağıtım komut dosyasına gerekli adımları ekleyin. Dağıtımdan sonra üretimde elle yapılan değişiklikleri yasaklayamıyorsanız ayrı bir yedek komut dosyası eklemeyi düşünün. Bu şekilde, sınırlı kaynağınız olsa bile süreci koruyabilirsiniz.

Ve evet, bu kesinlikle ayrılmış, ikinci bir repo olmalı, çünkü dev repo'dan tamamen farklı bir amacı ve farklı bir yaşam döngüsü var. Farklı bir işlem olan kaynak denetimi için değil, yalnızca yedeklemeler için kullanırsınız.