1

Тема: Використовуємо git для деплою локальних змін на віддалений сервер

(Створюю тему стосовно систем контролю версій саме тут, бо більш відповідного розділу немає)

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

На перший погляд найпростіший спосіб - використовувати git-hooks для цього. Спробував, сподобалось, написав статтю з цього приводу.

А який спосіб використовуєте ви? Через IDE? Чи може: робите локальний архів з усіма файлами, перекидаєте його на віддалений сервер і розархівовуєте?

Подякували: 221VOLT1

2

Re: Використовуємо git для деплою локальних змін на віддалений сервер

система така :
Є dev server на якому розміщений головний репозиторій.
Після того як ми зробили push локального репозиторію, дані попадають на дев сервер
Дальше з цього сервера розкидуємо зміни по інших серверах.
Якщо у вас 1н сервер то з git-hook цілком хороший варіант. Можна додати ще фішку що перше проганяємо тести а дальше уже закидуємо дані куди треба.

П.С. Синхронізуємо через rsync

Подякували: 221VOLT1

3

Re: Використовуємо git для деплою локальних змін на віддалений сервер

Відома мені стандартна схема передбачає:
1. комп розробника (чи декількох розробників);
2. сервер для тестів, який має бути ідентичним до production-сервера;
3. production-сервер;
4. push має попадати в робочі директорії тест-сервера та production-сервера, лише у випадку спрямування його у гілку master.

Таким чином, розробники мають два remote в git: тест-серер та продакшн-сервер. Якщо вони щось розробляють, що ще не годиться навіть для тестів, то push вони роблять у якісь інші гілки, не у master.

В такому разі, скільки б не було розробників, всі вони можуть робити push/pull з тестового сервера...

Тому я не бачу причин чому не використовувати таку схему не одному, а зразу декільком розробникам.

4 Востаннє редагувалося ktretyak (19.06.2016 22:40:45)

Re: Використовуємо git для деплою локальних змін на віддалений сервер

До речі, для тестового сервера завжди треба передбачати можливість створення snapshots. Якщо якийсь тест пройшов невдало, то легко можна відкотитись до останнього снепшота. І навпаки - якщо тест пройшов успішно і доходить справа до впровадження цих же змін на продакті, то робиться черговий снепшот.

Я у себе на локальній віртуалці роблю тестовий сервак...

5

Re: Використовуємо git для деплою локальних змін на віддалений сервер

ви дурні, не ображайтесь, замість тисячі слів напишу чого так, DVCS є централізовані та розділені, в останній шо ви внесли, вирішеє вже керівник проекту, так як код розробника знаходиться на своєму ПК. А до доповнення дурні, вам там навіть git не підходить, а ви граєтесь, бо то Торвальдс, там ядро лінукс ...

- Поганому трояну фаєрвол заважає
- Ніколи не програмуйте та не пийте пиво
Якщо ви з першого разу написали програму, в якій немає жодної помилки, повідомте про це системного програмісту: він виправить помилки в компіляторі

6 Востаннє редагувалося iovchynnikov (20.06.2016 12:34:41)

Re: Використовуємо git для деплою локальних змін на віддалений сервер

Щось у вас взагалі слабо з CI/CD... Хоча цим страждають багато починаючих web пехапе студій.

Не треба винаходити колесо :)
Почитайте про continuous deployment/delivery.

Я особисто використовую такий варіянт:
0) Уся розробка відбувається у кожного розробника у його локальному середовищі. Середовища НЕ використовуються розробниками. Середовище інтеграційне для тестіів qa та acceptance tests.
00) Деплоймент на продакшн це останній крок циклу/ітерації розробки. Ніколи ніхто не робить деплой з локального середовища.

1) Git
2) Gitflow: master бранч лише для продакшн коду/релізів; develop для integration environment.
3) Jenkins
4) Дженкінс наслуховує зміни у цих бранчах і окремо їх будує
5) через плагін налаштовую delivery pipeline що робить деплой різних білдів на різні середовища: master на продукцію, develop на тестове середовище (nightly builds)
6) на стороні серверів доставку очікують баш скрипти, що далі виконують деплой.

Може бути у нагоді: http://www.tutorialspoint.com/jenkins/j … oyment.htm

7

Re: Використовуємо git для деплою локальних змін на віддалений сервер

iovchynnikov, відчувається, що ви себе позиціонуєте як експерта у цій справі. Який у вас досвід розробки? - Це перше
І друге - хто вам сказав, що деплой не робиться із локального середовища? Звідки така впевненість?

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

8 Востаннє редагувалося iovchynnikov (20.06.2016 12:01:50)

Re: Використовуємо git для деплою локальних змін на віддалений сервер

ktretyak написав:

iovchynnikov, відчувається, що ви себе позиціонуєте як експерта у цій справі. Який у вас досвід розробки? - Це перше
І друге - хто вам сказав, що деплой не робиться із локального середовища? Звідки така впевненість?

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

А давайте почнемо з того, що єдина моя порада Вам була це почитати про continuous deployment/delivery, ок?  Я не експерт і все, що написано нижче - метод, та констрейнти, котрі прийшли з досвіду. Вам ніхто не пропонував його використовувати. Якщо Вас так дуже цікавить мій досвід, шукайте на linkedin.

Така впевненість теж, як і у Вас, з особистого досвіду. На жодному нормальному проекті де я був, ніколи ніхто не робив деплою зі свого локального середовища. Більше того, як Ви й зазначили, у більшості випадків девелопер навіть не має "фізичного" доступу до продукції. Я не теоретизую, я вважаю що має бути розділення відповідальності, автоматичні білди та визначений воркфлоу, який не полягає на "Я просто зроблю маленьку зміну у конфігу на проді і це нічого не зламає". Є навіть такі думки, що девелопер НЕ хоче мати доступу взагалі: якщо щось піде на проді не так, то більше вірогідність, що це не моя вина. [1] Якщо Вас цікавить холівар на цю тему, тут [2] достатньо інфи чому доступ має бути закритий.

Я тут не свою точку якусь нав'язуюсь. Як і сказав, не треба вигадувати колесо. Є усталені, перевірені воркфлоу для CI/CD. Є спеціальні інструменти, які вже існують з десяток років (Hudson (->Jenkins) Initial release 2005y). Залишилося лише їх собі прикрутити.

[1] http://stackoverflow.com/a/4147591/2180005
[2] http://stackoverflow.com/questions/4147 … production

Подякували: funivan1

9

Re: Використовуємо git для деплою локальних змін на віддалений сервер

Якщо ви не експерт, то не використовуйте Caps Lock, коли пишете НІХТО І НІКОЛИ... яке поєднується з оцінкою "слабенько щось у вас..." - так буде більш зрозуміло що ви це пишете виходячи з власного досвіду...

Подякували: iovchynnikov1

10

Re: Використовуємо git для деплою локальних змін на віддалений сервер

reverse2500 можна посилання на DVCS і як ви використовуте це?

iovchynnikov у нашому проджекті після кожного коміту проганяються тести. Залишилось робити деплой при успішному білді - якщо гілка мастер. Або якщо тест провалився відправляти нотіфікейшин.

11

Re: Використовуємо git для деплою локальних змін на віддалений сервер

reverse2500 можна посилання на DVCS і як ви використовуте це?

fossil
люблю мінімалізм, більше, що я працюю, воно навіть не в WWW, десь є посилання на chiselapp, думаю розребусь з проблемами і візьмусь за нього

- Поганому трояну фаєрвол заважає
- Ніколи не програмуйте та не пийте пиво
Якщо ви з першого разу написали програму, в якій немає жодної помилки, повідомте про це системного програмісту: він виправить помилки в компіляторі
Подякували: 0xDADA11C71

12

Re: Використовуємо git для деплою локальних змін на віддалений сервер

funivan написав:

iovchynnikov у нашому проджекті після кожного коміту проганяються тести. Залишилось робити деплой при успішному білді - якщо гілка мастер. Або якщо тест провалився відправляти нотіфікейшин.

Дуже добре ви робите. Це звичайний CI. Щось на кшталт такого я й пропоную. Я для цього у домашніх проектах використовую github+travis-ci.org, на роботі jenkins.