Kaynak kontrolüne geçiş yapma

Bizimki, yaklaşık 100+ web sitesine işlevsellik sağlayan tek amaçlı bir PHP web uygulaması geliştiren oldukça küçük bir şirkettir (3-4 programcı ve 3-4 site tasarımcısı). Birkaç yıl boyunca, oldukça iyi çalışan ayrı bir geliştirme ve üretim ortamında çalıştık. Programcıların hiçbir zaman gerçekten çatışmayacağı ve kaynak kontrolü olmadan çalışmanın daha uygun olacağı her zaman yeterince ayrı özellik geliştirildi; veri kaybı riski olmasına rağmen ve dosyalardan adil bir şekilde payımıza düştük.

Diğer bir husus, tasarımcılarımızın teknoloji konusunda bilgili olmamalarıdır (WYSIWYG kullanmak yerine html işaretlemesiyle tanıştırdım). Versiyona geçmekte tereddüt etmenin nedenlerinden biri budur.

Ancak, 100'den fazla siteye ulaştığımıza ve geliştirme ekibi büyüdüğüne göre, prosedürlerimizi standartlaştırmaya çalışıyorum ve kaynak kontrolü programcılar kadar mantıklı bir adım gibi görünüyor. Bunun yama dağıtımlarımızı da hızlandıracağını umuyorum.

Ne yazık ki, bir kaynak kontrol sistemi kurma konusunda çok sınırlı deneyimim var. Benzer bir kurulumu olan veya geçiş yapma deneyimi olan kişilerden duyduğum şey:

1) Her şeyi (siteler, css, html şablonları ve uygulama kodu) sürümlendiriyor ve böylece tasarımcıları sürüm oluşturmayı öğrenmeye zorluyor musunuz? Yoksa sadece uygulama kodu üzerinde çalışan geliştiriciler mi?

2) Kaynak kontrolünü ilk kez ayarlarken dikkat edilmesi gereken bazı tuzaklar nelerdir?

3) Kaynak kontrolü için dev => üretim ipuçlarının dağıtımı.

Görüşleriniz için teşekkürler.

Düzenleme 1: Dang. Herkes şimdiye kadar her şeyi kontrol etmenizi tavsiye ediyor. Bu, saçlarımı erken kaybetmeme neden olacak. Muhtemelen yakın gelecekte yeni bir soru ortaya çıkaracaktır. Şimdiye kadar tavsiye için teşekkürler, gelmeye devam!

Edit 2: Pek çok iyi yanıt ve çeşitli sürüm kontrol sistemlerine bakacağız. Herkese cevaplar için teşekkürler!

Tasarımcılar için bile her şeyin sürümlendirilmesi faydalıdır. İyi bir eğitim ile iyi uygulanırsa, bence bunu külfetli olmaktan çok daha yararlı bulacaklar.

Yeni başlıyorsanız, git veya mercurial gibi dağıtılmış bir sürüm kontrol sistemi kullanmanızı şiddetle tavsiye ederim . Bu dünyadaki genel eğilim ve birçok avantajı var. Bağlantısı kesilmiş bir modda çalışmak kolaydır, ağ bağımlılığı yoktur ve hala sürüm kontrolü altında özel, cilasız çalışma yapma yeteneği, hazır olduğunda merkezi olarak her şeyi kontrol eder.

Ve, otoriteye ya da herhangi bir şeye itirazda bulunmak için değil, Joel Spolsky'nin konu hakkında ne söylediğine bakın . (Seçenek alıntısı: "Subversion = Sülükler. Mercurial ve Git = Antibiyotikler.") Diğer şeylerin yanı sıra, bu yeni sistemlerin geleneksel sürüm kontrolünden farklı olarak yeni bir zihinsel model kullanması ilginç bir noktaya işaret ediyor - bu yüzden bu tür yaklaşım başından beri bir kazançtır.

Ben her şeyi sürüm kontrolü altına koymak söyleyebilirim. Her şey işe yaradığında, çoğu SCM sistemi için sunucuda çok fazla disk alanı gerektirmeyen bir etikete kopyalayabilirsiniz.

Başlangıç ​​tuzaklarına gelince, çok endişelenmemelisiniz; sunucuya her şeyi taahhüt edin ve doğru değilse, karıştırıp daha sonra ek şeyleri silebilirsiniz. Taahhüt etmeyeceğim tek şey, kaynaktan oluşturulmuş eserler, yani, java kodu dosyaları sürüm denetimine aittir, ancak derlenmiş sınıfları veya "kaynaktan oluşturulmuş" ikili dosyaların tüm ISO'larını / DVD'lerini içermez.

Üretime dev kolaydır, her büyük kilometre taşında bir şube oluşturur. Sürüm kontrol sistemindeki dizin düzeni genellikle şuna benzer:

/ gövde / proje / şube / proje / sürüm1 / şube / proje / sürüm2 / şube / proje / sürüm3

Diyelim ki ürünün 2. sürümünde bir hata buldunuz, o şubeye gidin, düzeltin ve 2.1 sürümünü yayınladınız. Yeni sürüm 4 için / trunk / project klasörü üzerinde çalışırken, hangi özelliklerin ileri ve geri birleştirildiği size kalmış.

SCM kool-yardım içicilerinin sizi kandırmasına izin vermeyin, orada popüler sürüm kontrol sistemleri arasında çok az fonksiyonel farklılık var, yani Subversion ve Git. Ekibiniz için en önemli şey, bu sunucuların mevcut araçlarınızla ne kadar iyi entegre olacağı olacaktır. Ben de WYSIWYGs sevmiyorum ama eclipse-php veya sunucu ile uyumlu diğer IDE'leri olması güzel.

Ben bir geliştiriciyim ve daha önce BT yöneticisi olarak çalışıyordum.

Özel sorularınızı cevaplamak için:

1) Evet, Sürüm her şey.

2) İnsanların öğrenmesi için bir kukla sürüm kontrolü deposu ve kukla projesi kurmanızı öneririz.

3) Üretime giren versiyonları etiketleyin. denemeler bile. Ardından, her zaman birinin çalıştığı belirli bir sürüme göz atabilirsiniz.

CVS sorusunu etiketlediğinizi görüyorum.

Benim önerim, kullanımı çok kolay hale getiren TortoiseSVN ile birlikte, yıkıma ciddi bir şekilde bakmak. Ayrıca bir TortoiseCVS de var.

Sürüm kontrolü için kurum içi bir eğitici çalıştırmanızı öneririm. Geliştiricileriniz / tasarımcılarınız daha önce bununla karşılaşmadıysa şaşırırım. Tortoise sadece kullanıcı dostu yapar.

Web arayüzlerinden birini cvs veya subversion'a kurmak da yararlı olabilir.

CVS üzerinde yıkımı önermemin sebebi, CVS çok iyi olmakla birlikte, ciddi tasarım ve uygulama problemleri olmasıdır. Benim için biggies vardı: 1) Dizinler sürüm olamaz 2) İkili dosya işleme metin olarak varsayılan bir çok şey olarak çok iyi değil. 3) Atomik işlem yapılmaz. 4) Sık sık karışıklık ve kod dosyaları el ile kaldırmak zorunda etrafında kilit dosyaları bırakarak hatırlıyorum. Sizin rm kilit dosyaları beri bu yolsuzluk için yer vardı. 5) SSL desteği ve kullanıcıları / şifreleri yönetme

Subversion temel olarak bu sorunların çoğunun muhtemelen diğer birçok sorunu çözer. Ayrıca harici olarak (aslında kullandığım) birçok gelişmiş özelliğe sahiptir. Ve muhtemelen kullanıcıları / grupları, yararlı bulabileceğiniz etkin bir dizine bağlamaktır. O zaman mevcut olmayan CVS kullandım. Şimdi olabilir, kontrol etmedim.

Muhtemelen başınızı kullanarak svn etrafında almak için en büyük fark etiket oluşturmak değil olmasıdır. Bunun yerine, proje dizininin Etiketler klasörüne kopyalandığı ve bir ad verildiği durumlarda kopya gibi görünen şeyleri oluşturursunuz. Belgelere bir göz atın ve ne demek istediğimi anlayacaksınız. Garip göründüğünü biliyorum ama alışmaya başladın.

Bu web sitesi bazı yararları olabilir (bunun için kefil olamam da): php web siteleri için modüler bir svn deposu kurma http://www.howtoforge.com/set-up-a-modular-svn-repository-for -web sitelerini -php

Ve - üzerinde görünen bilgelik çok büyük bir saygıyla olan bilge - versiyon kontrolünün rolloutunda izleme sistemleri rollout gibidir. Müşterilerim "ne izlemeliyim" diyor ve açık cevap "her şeyi izliyor". Ancak bu hoş bir haber değil: Her biri 20-30 sistem değişkeni artı bir dizi kullanıma özgü değişken olan 350 sistem var ve hepsi de yararlı bir şekilde izlenebilir; ama benden sadece bir tane var ve iki hafta içinde bazı sonuçlar görmek istiyorlar.

Bu yüzden, en iyi uygulamanın her şeyi sürüm kontrol etmek olduğunu kabul etsem de, ilk etapta pratik değilse, kontrol eksikliği şimdiye kadar en fazla soruna neden olan şeyleri kontrol ederek başlayın .

Çoğu kesinti uygulama kodundan kaynaklanıyorsa, aşağıdakileri kontrol ederek başlayın; çoğu planlanmamış CSS yamalarıyla kontrol ederseniz; ve bunun gibi.

Bu sadece size yatırım için en iyi getiriyi sağlamakla kalmaz, aynı zamanda gelecekte sürüm kontrolü kullanımını genişletmek için sağlam nedenler de sunar: "Uygulama koduna sürüm kontrolü eklediğimizden, 30 dakikadan uzun süren kesintiler ayda 11'den 2'ye düştü. Bu ikisine statik HTML değişikliklerinden kaynaklandığını, bu nedenle bunları bir sonraki sürümle kontrol etmeyi amaçlıyoruz. "

Aşamalı sunum ayrıca kuruluş içinde kalifiye kullanıcılar da sunar. Evet, altı uygulama geliştiricisine de sistemi nasıl kullanacaklarını öğretmek zorunda kaldınız, ancak öğrendiler ve bu konuda sorun yok; şimdi sistemi CSS ekibine sunma zamanı geldiğine göre, üç ay önce yaptığınızdan altı şirket içi uzmanınız daha var. Bu zamana kadar dönüşümleriniz bile olabilir; Zararlı bir değişikliği derhal reddetme yeteneğiyle kıçını kurtarmış bir geliştirici, CSS ekibine en iyi evangelistiniz olabilir.

Düzenleme 1: Bu rotaya gitmeye karar verirseniz, en ucuz olarak bir üretim kutusuna, cips gibi ucuz bir geri döndürmez üstte tripwire eklemektir . Bu şekilde, eğer şeyler Molası ama VCS o anda, hızlı etkenleri belirleyebilirsiniz sorumludur şey olmadığını söyledi gelmiştir hem düzeltme hızlandırır ve sürüm kontrolü için bir sonraki aday ileri süren değişti.

Sürüm her şeyi kontrol eder. Sürüm denetimi altında HTML dosyalarına sahip olmanın ve ardından CSS'de kontrol edilmeyen bir değişiklik nedeniyle tamamen vidalanmış bir siteye sahip olmanın bir anlamı yoktur ve bu nedenle kolayca geri alınamaz.

Tuzaklar: Kabul edilebilir derecede sınırlı sürüm kontrolü kullanımım sırasında şahsen hiç karşılaşmadım.

Dağıtım: Şu anda hem iş yerinde hem de evde Windows kutularında barındırılan alt sürüm kullanıyorum. Windows sadece mevcut olanı olduğu için. Aksi takdirde kolayca başka bir işletim sistemi olabilirdi. Teknoloji olmayan kullanıcılar için anahtar i ithalat, ihracat, taahhüt, diffs, vb işlemek için basit bir GUI tabanlı araç vermek için. Hangi araç kullanmak için kullanılan OS ve VCS sistemine biraz bağlı olacaktır.

Kullanın: Kod değişiklikleri yaparken sık sık test edip işlerim. Bu, vidaladığımda gerektiği kadar geri gitmeme izin veriyor. Ayrıca, çeşitli düzeltmeleri karşılaştırarak ve kodun bölümlerini kopyalayarak, kodun başka bir kısmındaki bazı şeyleri düzeltmek için önceki bir sürüme geri dönmem gerektiğinden her değişikliği kaybetmek zorunda değilim.

Ek avantaj: Kaynak deposuna bir VPN veya güvenli bağlantı üzerinden erişerek kullanıcıların evden veya başka bir yerden çalışmasına izin verebilirsiniz. örneğin evde bir fikir edinebilir ve iş kodumu orada ve sonra düşünceyi kaybetmeden önce düzenleyebilirim.

Sürüm her şey.

Dağıtım, bu sitelerin her biri için ne kadar "özelleştirmeniz" gerektiğine bağlıdır. Bir veya iki yapılandırma dosyası dışında özdeş iseler, kodun bir kopyasını kontrol edebilir ve küçük değişiklikler yapabilirsiniz. Gerektiğinde, istemcilerin her biri için sürüm denetiminizin güncelleme komutunu çalıştırın.

"Ödeme doğrudan müşterinin sitesine" dağıtım modeliyle devam ederseniz, sunucunuzun sürüm kontrolü dizinlerine erişimi dışladığından emin olmak istersiniz, böylece kullanıcılar http://example.com/ adresine göz atamaz. Git / ve içine bakmak. Ayrıca, bir site güncellemesinin haywire'a gitmediğinden emin olmak için her müşteri için kesinlikle bir test ve üretim sanal ana bilgisayarım olurdu . Özellikle bireysel istemcilerin dosyalarında özel değişiklikler yapıyorsanız, değişiklikler yayınlanmadan önce çakışmaları ele almanız gerekir. Bu durumda, test sanal ana bilgisayarını kullanıma alır / günceller ve her şey yolunda gittiğinde, test sanal ana bilgisayarını üretim sanal ana bilgisayarına kopyalarsınız.

İnsanların sürümün ne olduğu hakkında söyledikleri iyi.

Eğer yıkıma gitmeye karar verirseniz Bitnami Trac yığınını denemenizi tavsiye ederim; http://bitnami.org/stack/trac

Sizin için yıkımı ayarlamayı basitleştirir, değişiklikleri ve hataları takip etmek için bir biletleme sistemi (bu aşamada kullanmayı seçebilirsiniz veya seçemezsiniz) ve geliştiricilerinizin nasıl kullanmasını istediğinizi belgelemek için kullanabileceğiniz bir wiki ile birlikte gelir sistemi.

Tüm Windows geliştiricilerinize TortoiseSVN verin. Herkese birkaç svn komut satırı temeli öğretin.

Günün sonunda araç, geliştiricilerinize aşılamanız gereken zihniyetten daha az önemlidir. Umarım yakında sürüm kontrolünün A Good Thing olduğunu görürler çünkü işlerini kaybetmelerini durdurur ve onları bilinen iyi durumlara hiçbir yere götürmeyen çıkmaz uçlardan geri dönmelerine izin verir. Faydalar (hafif) genel giderden daha ağır basar.