Перехід до управління джерелом

Наша - невелика компанія (3-4 програмісти та 3-4 дизайнери сайтів), яка розробляє універсальний веб-додаток PHP, який забезпечує функціональність приблизно на 100+ веб-сайтах. Ми пару років працювали в окремому виробничому та виробничому середовищі, яке працювало досить добре. Завжди було достатньо розроблених окремих функцій, щоб програмісти ніколи не стикалися, і було зручніше працювати без контролю джерела; незважаючи на те, що це загрожувало втратою даних, і ми мали неабияку частку файлів, які пропали несподівано.

Інша думка полягає в тому, що наші дизайнери не мають технологій (я представив їх для розмітки html, замість того, щоб використовувати WYSIWYG). Це було однією з причин вагатися щодо переходу на версію.

Однак тепер, коли ми дійшли до 100+ сайтів і команда розробників зростає, я намагаюся стандартизувати наші процедури, а контроль над джерелами здається логічним кроком, наскільки програмісти йдуть. Я сподіваюся, що це також прискорить наше розгортання патчів.

На жаль, у мене дуже обмежений досвід налаштування системи управління джерелами. Що мені цікаво почути від людей із подібними налаштуваннями чи досвідом перемикання:

1) Ви версійте все (сайти, CSS, HTML-шаблони та код програми) і тим самим змушуєте дизайнерів вивчити версії? Або це просто розробники, які працюють над кодом програми?

2) На які підводні камені слід звернути увагу, спочатку налаштовуючи джерело управління?

3) Розгортання dev => виробничих порад для контролю джерел.

Дякую за все розуміння.

Правка 1: Данг. Усі поки що рекомендують контролювати все. Це змусить мене рано втратити волосся. Це, мабуть, викличе нове питання найближчим часом. Дякуємо за пораду до цього часу, продовжуйте дійти!

Редагування 2: Дуже багато хороших відповідей, і ми розглянемо різні системи управління версіями. Дякую за відповіді всім!

Корисно все переосмислити, навіть дизайнерам. І якщо це буде добре виконано при гарній підготовці, я думаю, що вони вважають це кориснішим, ніж обтяжливим.

Якщо ви тільки починаєте, я настійно пропоную скористатися такою системою контролю версій, як git або mercurial . Це загальна тенденція у світі, і переваг є багато. Працювати в відключеному режимі легко, без залежності від мережі та можливості робити приватні, неполіровані роботи, які все ще знаходяться під контролем версій, перевіряючи все централізовано, коли воно готове.

І не вдаватися до звернень до влади чи чогось іншого, але перевірити, що Йоель Спольський має сказати на цю тему . (Цитата вибору: "Subversion = Leches. Mercurial and Git = Antibiotics.") Серед іншого, він наголошує на цікавому моменті, що ці нові системи використовують нову ментальну модель, відмінну від традиційного контролю версій - ось чому потрапляють у подібний тип підхід від початку - виграш.

Я б сказав, поставити все під контроль версій. Як тільки це все працює, ви можете скопіювати його в тег, який для більшості систем SCM не потребує великого місця на диску на сервері.

Що стосується початкових підводних каменів, вам не слід було б сильно хвилюватися; передати все серверу, і якщо це неправильно, ви можете перемістити його та видалити зайві речі пізніше. Єдине, що я б не робив - це артефакти, які створюються з джерела, тобто файли коду Java належать до контролю версій, а не складені класи або цілі ISO / DVD-файли бінарних файлів ", побудованих з джерела".

Розробити виробництво легко, на кожному важливому етапі створити галузь. Макет каталогів у системі управління версіями зазвичай виглядає приблизно так:

/ магістраль / проект / гілки / проект / версія1 / гілки / проект / версія2 / гілки / проект / версія3

Скажімо, ви знайдете помилку у версії 2 продукту, переходите до цієї гілки, виправляєте її та випускаєте версію 2.1. Весь час, коли ви працюєте над папкою / trunk / project для нової версії 4, і саме від вас залежить, які функції об'єднуються вперед і вперед.

Не дозволяйте споживачам, які споживають коол SCM, вас обманюють, між популярними системами контролю версій там дуже мало функціональних відмінностей, а саме Subversion та Git. Найважливішим для вашої команди буде те, наскільки ці сервери інтегруються з вашими існуючими інструментами. Мені також не подобаються WYSIWYG, але, безумовно, добре мати eclipse-php або інші IDE, сумісні з сервером.

Я розробник і раніше брав участь у роботі ІТ-адміністратора.

Щоб відповісти на ваші конкретні запитання:

1) Так, Версія все.

2) Запропонуйте вам створити сховище керованої керування версіями та фіктивний проект для людей, на яких можна дізнатися.

3) Позначте версії, які вводяться у виробництво. навіть випробування. Тоді ви завжди можете перевірити конкретну версію, яку хтось працює.

Я бачу, що ви позначили питання CVS.

Моя пропозиція - серйозно поглянути на підрив, а в поєднанні з TortoiseSVN, що робить його дуже простим у використанні. Також є TortoiseCVS.

Я пропоную вам запустити власний підручник з контролю версій. Я буду здивований, якщо ваші розробники / дизайнери раніше не стикалися з цим. Черепаха просто робить її дуже зручною для користувачів.

Також може бути вигідно встановити один із веб-інтерфейсів у відеореєстратор чи підрив.

Причина, по якій я пропоную підривати CVS, полягає в тому, що хоча CVS дуже хороший, він має деякі серйозні проблеми в розробці та впровадженні. Для мене великими проблемами були: 1) Ви не можете версії каталогів 2) Обробка бінарних файлів не надто хороша, оскільки багато речей за замовчуванням є текстовими. 3) Ніяких атомних зобов'язань. 4) Я пам’ятаю, що він часто псує і залишає файли блокування, які мені довелося видаляти вручну з магазину кодів. Для корупції в цьому процесі було місце для комерційних файлів. 5) підтримка SSL та керування користувачами / паролями

Субверсія в основному вирішує всі ці проблеми, ймовірно, багато інших. Він також має багато вдосконалених функцій, таких як зовнішні (якими я фактично користуюся). І це можливо, щоб зв’язати користувачів / групи в активному каталозі, який вам може бути корисним. У той час я використовував CVS, який був недоступний. Це може бути зараз, я не перевіряв.

Мабуть, найбільша відмінність, щоб обернути голову навколо svn в його використанні, полягає в тому, що ви не створюєте теги. Натомість ви створюєте те, що, схоже, є копіями, де каталог проекту копіюється в папку «Теги» і надає ім’я. Погляньте в документацію, і ви побачите, що я маю на увазі. Я знаю, що це виглядає дивно, але ти звикаєш до цього.

Цей веб-сайт може принести користь (хоча я не можу поручитися за нього): Налаштування модульного сховища svn для веб-сайтів PHP http://www.howtoforge.com/set-up-a-modular-svn-repository-for -php-веб-сайти

З великою повагою до багато мудрості , яка з'являється вище - і це є мудрим - свитка контролю версій, як розгортання систем моніторингу. Мої клієнти кажуть «що слід контролювати», а очевидна відповідь - «моніторити все». Але це не вітальна новина: у них 350 систем, в кожній з яких є 20-30 системних змінних плюс купа змінних, що стосуються використання, і за ними можна було б корисно відслідковувати; але я тільки один, і вони хотіли б побачити деякі результати протягом тижня.

Тож хоч я згоден, що найкраща практика полягає в тому, щоб контролювати версії всього, якщо це не практично в першу чергу, почніть з контролю над тими речами, відсутність контролю яких викликав у вас більшість проблем досі .

Якщо найбільше збоїв викликано кодом програми, почніть з керування цим; якщо більшість за допомогою незапланованих патчів CSS, контролюйте це; і так далі.

Це не тільки дасть вам найкращу віддачу за інвестиції часу, але й надасть вам у свою чергу обґрунтовані причини для розширення використання контролю версій у майбутньому: "Оскільки ми додали керування версіями до коду програми, непередбачені відключення протягом 30 хвилин знизилися з 11 на місяць до 2. Ці два були викликані статичними змінами HTML, тому ми маємо намір контролювати версії наступними. "

Випускник також пропонує кваліфікованих користувачів всередині організації. Так, вам довелося навчити всіх шести розробників додатків користуватися системою, але вони навчилися, і з ними все в порядку; Тепер, коли прийшов час передати систему команді CSS, у вас є шість власних експертів, ніж ви робили три місяці тому. Ви можете до цього часу навіть конвертувати; розробник, який врятував свою дупу завдяки можливості негайного відшкодування згубних змін, цілком може стати вашим найкращим євангелістом для команди CSS.

Edit 1: якщо ви вирішили йти по цьому шляху, дешевий, як-чіпи блокіратора додати Tripwire на вершині, по крайней мере , на коробці виробництва. Таким чином, якщо що - то перерву , але VCS каже , що не було нічого , що в даний час несе відповідальність за, ви можете швидко визначити , що вже змінилися, що і прискорює виправлення і пропонує свій наступний кандидат для контролю версій.

Версія контролює все. Немає сенсу мати файли HTML під контролем версій, а потім повністю закрутити сайт через зміну CSS, яка не контролюється, і тому її неможливо легко повернути.

Підводні камені: я особисто не зустрічав жодного під час мого загальнодоступного контролю над версіями.

Розгортання: в даний час я використовую підривну роботу, розміщену на скриньках Windows, як на роботі, так і вдома. Windows лише тому, що це доступно. В іншому випадку це так само легко могла бути інша ОС. Ключ для нетехнологічних користувачів i - дати їм простий інструмент на основі графічного інтерфейсу для обробки імпорту, експорту, комісій, розбіжностей тощо. Який інструмент використовувати буде трохи залежати від системи ОС та VCS, що використовується.

Використання: Коли я вношу зміни коду, я тестую і виконую часто. Це дозволяє мені повертатися назад, наскільки це потрібно, коли я накручую. Плюс, порівнюючи різні версії та копіюючи частини коду, мені не доводиться втрачати будь-які зміни лише тому, що мені потрібно повернутися до попередньої версії, щоб виправити деякі елементи в іншій частині коду.

Додаткова вигода: Ви можете надати доступ до вихідного сховища через VPN або захищене з'єднання, дозволяючи користувачам працювати вдома або в іншому місці. наприклад, я можу отримати вдома ідею і відредагувати свій робочий код там, а потім, перш ніж втратити думку.

Версія все.

Розгортання залежить від того, скільки потрібно "налаштувати" для кожного з цих сайтів. Якщо вони однакові, окрім конфігураційного файлу чи двох, ви можете просто перевірити копію коду до них та внести незначні зміни. За необхідності запустіть команду оновлення для управління версіями для кожного з клієнтів.

Якщо ви перейдете з моделлю розповсюдження "замовлення прямо на сайт клієнта", ви хочете бути впевнені, що ваш сервер виключає доступ до каталогів управління версіями, щоб люди не могли переглядати http://example.com/. git / і зазирнути у ваші внутрішні організації. Крім того, я б обов'язково мав тестовий і виробничий віртуальний хостинг для кожного клієнта, щоб переконатися, що оновлення сайту не перебуває у сірійному режимі. Особливо, якщо ви вносите власні зміни до файлів окремих клієнтів, тоді вам потрібно буде вирішувати конфлікти, перш ніж зміни стануть активними. У цьому випадку ви б замовили / оновили тестовий віртуальний хост, і коли все працює правильно, ви скопіювали тестовий віртуальний хост у виробничий віртуальний хост.

Все, що люди говорять про те, що до версії, добре.

Якщо ви вирішили перейти на підрив, я можу порекомендувати спробувати стек Bitnami Trac; http://bitnami.org/stack/trac

Це спрощує налаштування підриву для вас, постачається із системою продажу квитків (яку ви можете вибрати на цьому етапі чи ні) для відстеження змін та помилок та вікі, який ви можете використовувати для документування того, як ви хочете використовувати ваші розробники система.

Подаруйте всім розробникам Windows TortoiseSVN. Навчіть усіх декілька основ командного рядка svn.

Зрештою, інструмент є менш важливим, ніж мислення, яке потрібно прищепити розробникам. Сподіваємось, вони незабаром побачать, що контроль над версіями - це Хороша річ, оскільки це зупиняє їх втрату роботи і дозволяє повернутися з тупиків, які ведуть їх нікуди назад до відомих хороших держав. Переваги переважують (незначні) накладні витрати.