Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Який інструмент використовуєтся для масової вставки файлів на продакт? Git?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Хоча з git`ом працюю вже досить давно, але ніколи не використовував його для роботи на продакті.

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

Така схема роботи була продиктована ще й тому, що мій продакт був на shared hosting`у, тобто без можливості використовувати git. Зараз же у мене з’явилась можливість працювати зі своїм виділеним серваком, а тому стало цікаво «Чи є вже готові схеми роботи з git для безболісної заливки даних на продакт? Чи можливо є якийсь інший інструмент для цього?».

Якщо все ж можна використовувати git, то яка схема роботи?

git fetch master

А що далі? =) Тут вже GUI не використаєш, але ж треба якось пересвідчитись, що ти тягнеш те, що треба і воно не змерджиться криво. Як це робиться?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Нарешті дійшла черга до ознайомлення із git-hooks для деплою — моя публікація з цього приводу

План перехода на гит:

1. Определить точно, какие файлы проекта не должны быть в репозитории и не должны контроллироваться гитом. Это будут конфиги и пользовательские файлы.
2. Добавить такие файлы и папки в .gitignore и удалить из репозитория, если они в нём были (stackoverflow.com/...itted-to-a-git-repository ).
3. для конфигов создать эталонные файлы (например config.php.dist), которые будут в репозитории и содержать шаблон файла настроек.
4. Написать инструкцию по поднятию проекта (что установить нужно, чтобы работало). Это не обязательно, но я бы советовал — даже если никогда не будет других разработчиков, это упорядочивает мысли и служит планом действий.
5. На продакшене создать бэкапы
6. В чистую директорию сделать git clone
7. Скопировать конфиги с существующей продакшн-версии, поправить если нужно соответственно новому расположению файлов проекта
8. Скопировать пользовательские файлы со старой версии, если такие есть
9. Поменять конфиг веб-сервера (apache/nginx) чтобы продакшн работал уже из новой директории, контроллируемой гитом.
10. Проверить, всё ли работает. Старую папку на время оставить, мало ли что.

План обновления:
0. Отключить сайт, если обновление включает много файлов или нужно будет обновлять схему БД или конфиги
1. Из папки с проектом на продакшне вызвать сначала git status, чтобы не было сюрпризов (вдруг какие-то папки с пользовательскими файлами не в gitignore оказались), затем git pull. Кодовая база обновлена
2. Обновить конфиги, если нужно
3. Применить патчи к БД (патчи держать в репозитории)
4. Включить сайт

Это вручную, но гораздо быстрее, чем заливать архивом или файлами по фтп. По автоматизации не подскажу — не имею опыта. В данной инструкции подразумевается, что актуальная и безбаговая версия лежит в мастере. Если нет — нужно в план перехода добавить переключение на нужную ветку (гуглить git checkout remote branch)

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

я не гуру GITа але в твому випадку ти зробив git init для двох різних каталогів де вже були файли? Здається так ти відразу отримаєш конфлікти навіть якщо файли ідентичні. В мому випадку на продакшені зроблений git clone і туди зливаються тільки зміни з мастера які локально змерджені і перевірені. Тобто з обох сторін один той самий репозиторій одна та сама гілка і все ок, правда це геморно бо треба робити все вручну.

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

можеш повидаляти папки .git і спробувати цей варіант

На продактному сервері, в оффлайн каталозі, зробив git init —bare ... В попередніх коментарях люди рекомендують вивчити pre- post-commit git hooks, що я зараз і роблю

На Digital Ocean правильно говорять. На сервері робиться bare repo, в якому на певний бранч вішається hook, що робить checkout з repo в активну директорію. Потім з дев-машини робиться git push server ..., і далі воно все деплоїться автоматично.

Крім того, що там написали, варто почитати про git update-index —assume-unchanged, —no-assume-unchaged якщо у вас є якись еквівалент конфігів.

Моя відповідь хоч і оверкіл до вашого запитання, проте, придивіться до Docker.
За останні роки робота з сервером видозмінилась, і з’явилось багато нових і зрузних інструментів окрім ручної заливки.
Сам користуюсь github.com/progrium/dokku на сервері для «своїх» проектів.

Це набір пре- пост-комміт хуків на git які налаштовані на сервері.
Мігрувати існуючим додатком, якщо зтикались з heroku, досить просто:
www.digitalocean.com/...alocean-dokku-application

Якщо у вас continuous delivery, зазвичай ставиться білд сервер (Jenkins, Bamboo, TeamCity) налаштовуються build — deploy задачі.

Безпосередьо деплой робиться «в лоб» — вашими shell сценаріями, або з використанням одного з devops тулкітів, як Ansible, Chef ...

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

Гляньте статті в інтернеті, нпр
blogs.atlassian.com/...al-continuous-deployment

www.atlassian.com/...orkflows/gitflow-workflow

Підписатись на коментарі