ибо хрен вам а не git в командной строке

вы привыкли публиковаться через git? Печально

дерьмохостинг -> не надо такие, VDS наше всё -> значит публикуемся через git.

В таком случае заявляю что ansible говно, ибо не умеет залить файлы по FTP в мастерхост (предварительно купив тариф).

Долой логику

вы привыкли публиковаться через git? Печально

месье собирает deb/rpm и распространяет их через репозиторий?

не, просто это дополнительная зависимость 1) от git 2) от удалённого репозитория 3) если он приватный, то нужно хранить deploy key 4) он хранит всю историю, и если когда-то туда по глупости попали приватные данные, то вам что теперь, rebase делать?

ну и размер

размер не проблема, если не класть туда то, что там лежать не должно

про приватные данные - та же история

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

эм, как бы... нехер на зеркало пенять, коль рожа кривая

не получаем, тут думать нечего

фтп - прошлый век и дыра в безопасности

админ должен не только думать о том, как развернуть приложение, как защитить конфиг через .htaccess, но и ещё про .git думать, который теперь тоже нужно учитывать

разве я где-то говорил про ftp?

фтп - прошлый век и дыра в безопасности

мы на прошлой работе нашей команде "программистов" (мадженто девелоперов) фтп убрали.... ты чё, сломали им всю работу. Они, бедненькие, чуть ли не в профсоюз написали, мол, какого хера)

я про то, что git - это не инструмент для развёртывания

админ должен не только думать о том, как развернуть приложение, как защитить конфиг через .htaccess, но и ещё про .git думать, который теперь тоже нужно учитывать

как там в прошлом живётся?) нормуль?)

я просто пример привёл

а чего пример такой свежий?) даёшь пример полувековой давности, чё уж там)

у вас есть дополнительные файлы, про которые нужно думать (.git), но которые совершенно начиг не нужны для функциональности приложения

если вы предпочитаете не думать, а тупо копировать весь репозиторий, ну что ж, ваше дело

я бы как минимум git archive использовал, и публиковал архив, а не весь репозиторий

не, просто это дополнительная зависимость 1) от git 2) от удалённого репозитория 3) если он приватный, то нужно хранить deploy key 4) он хранит всю историю, и если когда-то туда по глупости попали приватные данные, то вам что теперь, rebase делать?

1. она небольшая, экономия на спичках. Тем более git часто нужен для пкетов, которые ставятся через композер 2. не вижу проблемы 3. не вижу проблемы 4. вообще мимо кассы, это слабый аргумент против использования гитом в принципе, а не по поводу деплоя с использование гита

я бы как минимум git archive использовал, и публиковал архив, а не весь репозиторий

а еще можно посмотреть, какие есть на рынке инструменты и использовать деплоер и его git cache

Давайте докер образ отправлять по емейлу вложением

А то живём тут в прошлом веке

вы не "не видите проблему", вы игнорируете возможность её появления

если лень думать про человечий cd, капистрана в помощь) просто, быстро, легко запомнить)

вы не "не видите проблему", вы игнорируете возможность её появления

с удовольствием выслушаю Ваше мнение.

с её помощью даже самый конченный кретин способен без труда и последствий задеплоить приложение) проверено на куче профессионалов с любовью к фтп :)

п.с. "ваше" в данном случае пишется с маленькой буковки)

Ну давайте сравним два подхода 1) мне нужен веб сервер и php engine 2) мне нужен веб сервер и php engine, а потом ещё git, потом в fw прокрутите дырку до моего приватного gitlab, защитите мой deploy key в /root/.ssh/, потом в роутинге поставьте 403 на /var/www/web/.git. И да, нужен git, и ещё пара extension'ов для него. И ккампозер с симфони паставьте, и gcc, у меня всё собираться на серваке будет.

git clone - это часть сборки как минимум, а не часть публикации на сервер

докер в помощь)

высосано из пальца большинство ;)

не можешь в докер, капистрана) не можешь в капистрану - в окно прыгать

не, если вы с таким не встречаетесь - это же хорошо

высосано из пальца большинство ;)

особенно доставляет htaccess для гита) аж всплакнул)

докер - он как бы не от этого

особенно доставляет htaccess для гита) аж всплакнул)

вы предлагаете не _думать_ об этом?

или вы считаете, что это не надо защищать?

если у тебя корень проекта - является веб-рутом, у тебя уже проблемы ;)

вы предлагаете не _думать_ об этом?

я предлагаю открыть для себя чудный мир continuous delivery, ну или на худой конец расположить код ниже директории веб рута

но это сложна) проще в чатике дичь какую-то заливать

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

как скажешь :)

а мне показалось это ты тут лечишь какими-то страшилками ;) особо про прятать ключ от репозитория понравилось ;)

Ну давайте сравним два подхода 1) мне нужен веб сервер и php engine 2) мне нужен веб сервер и php engine, а потом ещё git, потом в fw прокрутите дырку до моего приватного gitlab, защитите мой deploy key в /root/.ssh/, потом в роутинге поставьте 403 на /var/www/web/.git. И да, нужен git, и ещё пара extension'ов для него. И ккампозер с симфони паставьте, и gcc, у меня всё собираться на серваке будет.

Т.е. весь этот зоопарк нужен на локальной машине? Нафига защищать deploy key? Он для readonly доступа, если машина скомпрометирована — пофик, сорцы\пароли уже утекли. Дырка в файерволе на исходящий трафик, не вижу проблемы. Любой нормальный фреймворк умеет паблик папку в каком-нибудь web|public, куда должен смотреть вебсервер, там уже подумали за тебя. Короче, лень писать дальше, скучно.

если используется ключ, то он так, для смеху чтоли?

ну и потерять код конкретного релиза, минимизированный и обфусцированный - это для вас тоже самое, что весь код потерять?

лол... ;)

о, я ждял этого))

я допускаю, что есть проекты, где это не важно

вы считаете, что так везде

мистер сисадмин, мы жалкие говнари на языке, который не умеет в обфускацию а минимизировать смысла нет

пфф. что ж вы думаете, в репе только php код может лежать?

"у меня так, значит так везде"

не забываем про всякие енкодеры

дружище, заканчивай с тяжёлыми наркотиками)

мистер сисадмин, мы жалкие говнари на языке, который не умеет в обфускацию а минимизировать смысла нет

тем не менее продолжаете спорить про деплой :)

дружище, заканчивай с тяжёлыми наркотиками)

только что :)

ну и потерять код конкретного релиза, минимизированный и обфусцированный - это для вас тоже самое, что весь код потерять?

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

ну и потерять код конкретного релиза, минимизированный и обфусцированный - это для вас тоже самое, что весь код потерять?

если твой код минимизирован и обфускирован - попробуй рассмотреть другую бизнес модель дистрибьюции кода не подразумевающую передачу третьим лицам

дискуссия была про сервер приложения и способ его разворачивания

git clone - это часть сборки как минимум, а не часть публикации на сервер

все так

я высказался против использования git для деплоя

ERROR: S client not available

git clone на продакшен сервере это sooo 2000late

сейчас мода на immutable infrastructure, контейнеры, кубернетисы и прочее

git на сервере... пфф

может еще каменный топор предложите?

мопед ваще не мой, см выше :)

мопед ваще не мой, см выше :)

я наискосок прочитал и вообще не понял о чем ты.... там конфликтуют часть высказываний. С одной стороны ты говоришь хорошие вещи вроде "git не средство развертывания" с другой говоришь про то что админ должен побеспокоиться о .git.

если ты о .dockerignore каком настройить и т.д. - уточнил бы

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

Если мне надо задеплоить приложение которое внутри докера, там с редисом, кроном, демоном и т.п - правильно понимаю что heroku / digital ocean это те сервисы которые позволяют это всё легко поставить? Если да, то что лучше взять если сервис ориентирован на СНГ аудиторию? В do ближайшие сервера в германии, а в хероку вообще хз

или как минимум думать, почему нам не надо этих телодвижений совершать

я высказался против использования git для деплоя

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

Если мне надо задеплоить приложение которое внутри докера, там с редисом, кроном, демоном и т.п - правильно понимаю что heroku / digital ocean это те сервисы которые позволяют это всё легко поставить? Если да, то что лучше взять если сервис ориентирован на СНГ аудиторию? В do ближайшие сервера в германии, а в хероку вообще хз

любая VDS

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

абсолютли

любая VDS

С меня сисадмин не очень, это самый просто способ?

начало дискуссии, если что

С меня сисадмин не очень, это самый просто способ?

ну погугли какие-нибудь клауд сервисы в рашке

абсолютли

Чёт, ты противоречишь сам себе. Опосредственно ты все-равно используешь git для деплоя, т.е. он все-равно в этом процессе участвует.

Чёт, ты противоречишь сам себе. Опосредственно ты все-равно используешь git для деплоя, т.е. он все-равно в этом процессе участвует.

не понял, git задействован только в момент сборки. Деплой уже оперирует артефактом сборки. никакого git-а

не понял, git задействован только в момент сборки. Деплой уже оперирует артефактом сборки. никакого git-а

Ну, я имею ввиду про CD.

Ну, я имею ввиду про CD.

что CD?

CD это про процессы

а не про тулы

ты можешь и собирать и деплоить через jenkins

и это может быть как 2 так и одна джобы (но скорее всего это будет разные этапы пайплайна)

и к деплою git отношения уже не имеет.

Continious Delpoyment разве не предполагает наличие git репозитория ?

Continious Delpoyment разве не предполагает наличие git репозитория ?

не совсем, CD предполагает что у тебя уже есть CI (и у большинства его нет, потому что при CI имеет место быть частая интеграция, скажем все пушат в мастер хотя бы раз в день)

CI предполагает что у тебя есть VCS

CD предполагает что у тебя деплоймент отделен от релиза функциональности (фичатоглы, брэнч бай абстрекшен) и что у тебя автоматизирован весь деплоймент и все хорошо с мониторингом

build: git -> build node -> artefact deploy: artefact -> app node

Ну так если я собираю релизный docker image который по сути имеет отношение к Continious Deployment. Разве это не деплой ?