1, push: git repo -> firewall -> internet -> bitbucket

2, clone: remote server <- bitbucket

Хранить свой код на стороннем сервере не вариант. В цепочке нужно только два.

ставишь гит на remote server, пущишь туда, и пост-апдейт хуком потом оттуда раскатываешь, как надо. чем не вариант? :)

git pull можно пробросить через самодельный ssh proxy на базе netcat

Скачать на локалхост не?

Хранить свой код на стороннем сервере не вариант.

Ну тогда храни на своём внешнем сервере :)

Стоп. А что, на remote server git тоже никак недоступен? Что мешает сделать не pull/clone с внешнего сервера на внутренний, а push с внутреннего сервера на внешний?

Проблема появляется только когда оба сервера снаружи недоступны. Тут или третий сервер нужен или грязное лобовое решение, типа btsync.

1. пробрось VPN между git и внешним сервером.

2. закинь git repo на удаленный сервер и пуш туда сразу, а потом пуляй локалхост

Всегда умиляюсь при виде сельского деплоя из гита

Всегда умиляюсь при виде сельского деплоя из гита

Просвети нас мудростью, о великий!

Хранишь тарболы с билдами в месте, доступном с удалённого сервера. Кладёшь их туда с девелоперской тачилы или с какого-нибудь абстрактного билд-воркера.

Так-то! Следующий вопрос.

Всегда умиляюсь при виде сельского деплоя из гита

...или вообще из любой VCS. Но это очень популярно.

деплой посредством гита это мракобесие.

деплой посредством гита это мракобесие.

Почему?

Хранишь тарболы с билдами в месте, доступном с удалённого сервера

Зачем добавлять лишнюю сущность?

потому что есть RPM DEB итп как раз для этого сделанные.

докучи есть спец системы puppet chef ansible и прочие. а гит для деплоя это ололо.

vpn? ssh-туннель? проброс портов? чем гит отличается от других сервисов?

RPM DEB

Жизнь слишком коротка, чтобы учиться собирать пакеты.

Fpm и нет проблем.

SyncNet же

к мессаге : посмотри SyncNet (хабр)

и, в догонку — PeerCDN

потому что есть RPM DEB итп как раз для этого сделанные.

Деплоить php приложения через deb/rpm и создавать на каждый проект по пакету? Мьсе знает толк в извращениях.

ещё на тему «нарезать репозитории»: сдаётся что тебе нужен какой-то CAM (content-addressable memory): Camlistore (сайт) или даже просто git на низком уровне, дёргая git objects: 0 object model ещё дерево и структура Git internals

ещё

чем гит отличается от других сервисов?

тем, что на низком уровне это CAM в обёртке VCS.

и создавать на каждый проект по пакету? Мьсе знает толк в извращениях.

учет установленных версий, преинсталл и постинсталл скрипты. пакеты для этого и придумали, что бы девелоперы на каждом сервере свои велосипеды не анонировали.

Деплоить php приложения через deb/rpm и создавать на каждый проект по пакету?
учет установленных версий, преинсталл и постинсталл скрипты

facepalm

про camlistore

facepalm

phpMyAdmin целиком писаный на php почему то в rpm и deb пакетах распространяется. может потому что это разумнее чем устраивать анархию ?

phpMyAdmin целиком писаный на php почему то в rpm и deb пакетах распространяется. может потому что это разумнее чем устраивать анархию ?

Извините, им пользуется много человек, а проектом который я деплою - я один его ставлю.
К тому же, я предпочитаю придерживатся правила KISS. Слышал о таком?

phpMyAdmin целиком писаный на php почему то в rpm и deb пакетах распространяется.

Потому что им пользуются все на сервере.

К тому же, я предпочитаю придерживатся правила KISS. Слышал о таком?

Велосипедить менеджер пакетов на баш-скриптах? Да, широко известный в узких кругах принцип.

Потому что им пользуются все на сервере.

А начиная со скольких пользователей программа должна быть в пакете? %)

А начиная со скольких пользователей программа должна быть в пакете? %)

Явно не при одном, как у tazhate.

Велосипедить менеджер пакетов на баш-скриптах?

Какой менеджер пакетов, о чем ты?
Есть оркестраторы, которые прекрасно выполняют свои фукнции.

Сейчас она тебе предложит развертывать сразу в отдельную виртуалку %)

А начиная со скольких пользователей программа должна быть в пакете? %)

Явно не при одном, как у tazhate.

Я думаю, что даже в его случае пользователей больше - таз и админ-сменщик, таз и админ, который будет после увольнения таза.

Сейчас она тебе предложит развертывать сразу в отдельную виртуалку %)

Ну, у меня проекты и так по ряду причин в отдельных виртуалках.

Но паковать пакет, загружать его на сервер теми же «баш скриптами» - это же ваще куль.
А если поднимать репу - её ж надо и в https и под пароль (не разу не видел еще пароленных реп под apt, интересно как там доступы сохранять) или вапще сразу тянуть впн в локалку, что как бы полностью перечит вопросу.

таз и админ-сменщик, таз и админ, который будет после увольнения таза

Если админ сменщик не осилит после моего увольнения поменять элементарный рецепт в ansible, я думаю, его очень быстро уволят.
К тому же, в таких случаях нормальные админы оставляют документацию, если не нет уверенности, что и кто это будет потом делать.

Извините, им пользуется много человек, а проектом который я деплою - я один его ставлю.
К тому же, я предпочитаю придерживатся правила KISS. Слышал о таком?

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

а через месяц будет расширение и на десятки серверов

Не будет.

вот ты только представь как у тебя будет деплой происходить - apt-get upgrade myphpsupersite

и ололо все обновилось.

Если админ сменщик не осилит [...] его очень быстро уволят.

То есть пользователей уже минимум трое %)

в таких случаях нормальные админы оставляют документацию

Не объясняй, почему такая схема может работать - это и так понятно. Любопытно было бы услышать, почему такая схема требует меньше затрат, чем схема с обычным репозиторием пакетов.

Оркестратор прекрасно выполняет свою функцию по доставке rpm-пакетов и их конфигурации.

А rpm прекрасно выполняет свои функции по версионированию, верификации, отслеживанию зависимостей и конфликтов.

Клоны узлов гитовых реп проекта подразумевают равноправие т.к. DCVS, следовательно нет разницы за фаером или где-то еще (в том числе у тебя).

Можно настроить хуки - при push автоматом деплоить на нужный target, но лучше явно. Pull/Clone из репы за фаером и со своей репы push на целевой хост.

Примерная отправная схема: http://toroid.org/ams/git-website-howto

Ключевое слово git bare.

Возможность деплоя с пол-пинка ценная характеристика качества проекта.

вот ты только представь как у тебя будет деплой происходить - apt-get upgrade myphpsupersite

А пакеты будет собирать прекрасная фея.

То есть пользователей уже минимум трое %)

Но задача (работа над проектом) одна и та же. А в случае с pma у трех пользователей будут разные задачи (разные бд).

Точно так же представляю:
ansible-playbook prod.yml

А rpm прекрасно выполняет свои функции по версионированию, верификации, отслеживанию зависимостей и конфликтов.

Ага, а теперь читаем пост не жопой и вникаем в суть проблемы.

Ну наконец-то в теме появился ответ :)
Спасибо.

Но задача (работа над проектом) одна и та же

Ну то есть количество пользователей значения не имеет.

в случае с pma у трех пользователей будут разные задачи (разные бд).

Или будет одна.