Це гарна ідея встановити Mercurial на вашому сервері та hg тягнути до розгортання?

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

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

Тож зараз ми працюємо так:

º----------BitBucket
º---------/
º--------/

Я та троє інших розробників hg pullз BitBucket вносимо наші зміни, потім hg pushдо BitBucket.

Тепер для розгортання комусь потрібно буде FTP останні файли до виробничого сервера.

Я думав встановити Mercurial на нашому сервері та використати hg clone(згодом hg pull) для оновлення версій у виробництві.

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

Це гарна ідея? Яких-небудь потенційних підводних каменів, які я, можливо, не бачу? Хтось тут робив щось подібне? Як розгорнути велику рамкову програму PHP (ми використовуємо Moodle)?

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

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

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

Спосіб здійснення атомних розгортань - це використання символьних посилань. Створіть каталог, що містить нові файли. коли все готове, змініть символьне посилання на використаний каталог. Якщо ви збережете стару версію навколо себе, ви також можете легко відкати.

Ще одна (на мій погляд краща) можливість: використовувати сервер побудови / сервер безперервної інтеграції.

Коротке коротке пояснення: це сервер (може бути власний, не потрібно в Інтернеті), який ви налаштували для моніторингу ваших сховищ, і кожного разу, коли в репостах з’являються нові набори змін, сервер створює ваш код ( AFAIK цього не потрібно в PHP) , запускає тести модулів і розсилає ваш код на веб-сервері.

Для отримання додаткової інформації перевірте ці посилання:

• Стаття у Вікіпедії про CI
• Питання про переповнення стека: у чому сенс "Build Server"?

Є багато різних продуктів для CI там , але єдиний, який я використовував поки що, це TeamCity . Дуже легко налаштувати ... насправді, це перший, який я спробував, і мені так сподобалось, що я дотримувався цього.

Альтернативне дешеве рішення:

Якщо налаштування сервера збирання докладає великих зусиль, або якщо ви хочете більше контролювати, коли саме ваш сайт розгорнуто, просто встановіть файл сценарію (Batch / Powershell в Windows або щось подібне на Linux / Mac), який витягує найновіша версія вашого сховища та FTP-файли на виробничому сервері.

В основному, це те саме, що і сервер збирання, тільки простіше.

Як би ви не вирішили це врешті-решт ... не забудьте якось автоматизувати це!

Ви хочете мати змогу розгорнутись одним натисканням кнопки / набравши одну команду, так що КОЖНО БУДЕ це робити, не знаючи нічого особливого та не допускаючи помилок - навіть у випадку катастрофи чи під напругою.

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

Напевно, важливішим, ніж ця неатомність, було б "як ти керуєш оновленнями схеми бази даних" - розгортання поганого коду таким чином робить виправлення таким простим. Велика проблема полягає в тому, коли ви розгортаєте оновлення, яке змінює базу даних, яку ви хочете відкрутити. Або якщо ви робите погані оновлення та пошкоджуєте дані.

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

Це чудова ідея, проте пам’ятайте про наступне:

• Намагайтеся не здійснювати фіксацію на сервері (хоча в деяких рідкісних випадках це має сенс, наприклад, встановлення плагіна або додавання ресурсів вмісту)
• Для тестування використовуйте сервісний етап або розгортання вторинного сховища
• Будьте завжди обережні, що hg update -Cне впливає на виробництво (тобто видаляйте важливі файли)
• Мають галузь виробництва та розвитку, розгортають лише галузь виробництва
• Трактуйте ресурси як резервну копію (наприклад, зображення для вмісту) та ігноруйте дані користувачів (наприклад, вкладення / завантаження, кеш-пам'ять тощо)
• Завжди мати чистий hg statusвихід на сервер (це допоможе вам переконатися, що ви ігноруєте речі як кеш)
• Не розгортайте сховище у веб-папці. Використовуйте символьні посилання поза публічним простором (наприклад, ln -s / myrepo / src / web / public_html / myapp)
• Будьте обережні, щоб не конфігурувати файли конфігурації версій (особливо з паролями бази даних чи іншими)
• Не використовуйте замість виробничої резервної копії, це резервна копія розробки для виробничого коду , а не виробничих даних

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

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