Як додати керування версіями до свого робочого процесу?


11

Я розробляю теми, їх багато. Мені видають PSD, кодують HTML / CSS, ляпають код у Wordpress та вносять виправлення, коли вони отримують QC'd. Клієнти можуть редагувати публікації блогу, як звичайні, або завантажувати фотографії за допомогою спеціального плагіна.

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

Запропоновані Git і Mercurial, і я хотів би скористатися цими інструментами, але я збентежений, як їх вписати в робочий процес.

Чи потрібно вимагати всіх змін на сайті на сервері розробки, а потім натиснути їх в реальному часі після затвердження? Що з написанням публікацій в блозі? Здається, що надмірно писати публікації на програмі Dev і натискати зміни в прямому ефірі, але як потім я синхронізувати бази даних, якщо вони редагуються на веб-сайті в реальному часі? Я переглянув Інтернет. Деякі вказівки будуть вдячні.


Я думаю, що це відноситься до позасезонного питання екосистеми. Дивіться тут для постійної дискусії .
Чіп Беннетт

4
@ChipBennett Я не згоден. Вітаються специфічні залежності WordPress між темами, плагінами та базою даних та те, як вони впливають на загальну практику розробників.
фуксія

@toscho Я, безумовно, міг переконатися в цьому; саме тому я вказав на дискусію про Мета. :)
Чіп Беннетт

Відповіді:


9

Перш за все, вам потрібно визнати, що тут є два робочі процеси: ваш та ваш клієнт.

Ваш робочий процес

  • Отримують PSD
  • Код HTML / CSS
  • Код WordPress шаблон
  • Розгорніть тему, щоб жити на сайті WordPress

Їх робочий процес

  • Придумайте необхідні зміни та надішліть вам електронний лист
  • Пишіть дописи
  • Завантажте фотографії

Питання

Здійснення контролю над версіями тут абсолютно не має нічого спільного з робочим процесом ваших клієнтів. Вся справа в тому, щоб відстежувати код, який ви використовуєте для теми WordPress. Усі ваші файли тем, користувацькі плагіни тощо повинні знаходитись у системі контролю версій (Git, Mercurial, Subversion або будь-якому іншому).

Потім ваш робочий процес стає:

  • Написати код
  • Внести зміни в систему управління версіями
  • Натисніть на зміни на виробничому місці
  • Отримати коментарі від клієнта
  • Написати код
  • Внести зміни
  • Написати код
  • Внести зміни
  • Натисніть на зміни на виробничому місці

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

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

Кодові зміни протікають від розвитку до виробництва.
Зміни бази даних протікають від виробництва до розвитку.


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

@EAMann Чудова відповідь, дякую! Єдине, що я хотів би додати до описаного вами робочого процесу - це написати код, внести зміни, перейти на сайт розробки, отримати коментарі від клієнта, ... Я не розглядав два окремі робочі процеси, тому що регулярно нам доведеться змінювати вміст для клієнтів. Інколи нам доведеться вводити HTML у вміст, щоб відповідати спеціальним запитам у вмісті (спеціальні стилі тощо). Іноді вони вимагають схвалення клієнта перед тим, як перейти в прямому ефірі, саме тому бази даних повинні синхронізуватися. Чи є найкращі практики для подібних налаштувань?
cfree

@Wyck Замість того, щоб видаляти вміст поряд із тематикою, має сенс розділити два процеси. Мені подобається ідея областей розробки для тематизації та постановочної області для передачі вмісту незалежно один від одного. Єдине питання, яке я бачу, це те, що клієнти люблять бачити як тему, так і вміст (сайт у повному обсязі; статичні сторінки) перед його запуском в прямому ефірі.
cfree

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

3
Ще немає, це справді шип у стороні WordPress, але не конкретно питання WordPress, оскільки у багатьох CMS є ця проблема, про це ви можете прочитати тут wordpress.stackexchange.com/questions/119/… докладніше, глибше Сценарії існують там, але більшість з них є вдома, оскільки вони специфічні для певного середовища.
Вік

1

Ви можете використовувати програмне забезпечення, яке синхронізує бази даних. Але також є можливість версії самих даних на зразок http://chronicdb.com


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

1

Я просто написав ґрунтовну відповідь на це на інше питання. Особисто я використовую git, і це фантастично. Що стосується початку роботи, я рекомендую перевірити http://gitref.org/ та http://help.github.com/mac-set-up-git/ . Якщо ви тип книги, я прочитав цю книгу, і вона, безумовно, коштує ціну на книгу в 22 долари. Змусьте зробити це, ви не пошкодуєте про це рішення.


Дякую, мені доведеться повернутися до цього. Налаштування бази даних master / slave звучить цікаво. Дякую за вказівки
cfree
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.