К группам разработчиков(WEB)

[Sly_tom_cat]

AndreyChursin, вы все в одну кучу сваливаете - вот у вас и голова болит.

Есть группавая разработка и контроль версий/бранчей и т.п. и для этого git подходит - он для этого и создавался.

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

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

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

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

[Punko]

.....

Вот в этом и есть ваша ошибка. Автоматизация существующего бардака приведет к автоматизированному бардаку....

Извинияюсь за небольшой оффтоп, но это изречение достойно того, чтоб запомнить его до конца жизни. Шикарно сказано

[Sly_tom_cat]

(Нажмите, чтобы показать/скрыть)

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

[AndreyChursin]

AndreyChursin, вы все в одну кучу сваливаете - вот у вас и голова болит.

Есть группавая разработка и контроль версий/бранчей и т.п. и для этого git подходит - он для этого и создавался.

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

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

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

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

Работаю в дизайн студии...
Ну я так сказать попал в такие условия, когда есть 40 разных сайтов которые нужно администрировать, вносить правки(иногда очень мелкие) и прочее. Есть начальник, который так же вносит правки.

Принцип разработки в общем и целом всех устраивает, все правки(не значительные) вносятся по живому сайту, поставил ограничение на ip-студии и смотришь как работают вносимые правки. Связка FileZilla + SublimeText иногда даёт сбой, т.к. затираются чужие правки.
Вот у меня и возник вопрос, возможно ли на таком уровне работать и упорядочить бардак... 
Да и вообще интересно, как люди организуют такого рода работу.

[scsiman]

AndreyChursin,

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

Никогда. И если кто-то положит сайт наглухо, концов не найдёте. Нельзя так.

[AndreyChursin]

AndreyChursin,

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

Никогда. И если кто-то положит сайт наглухо, концов не найдёте. Нельзя так.

Понятно что есть опасность положить сайт лишней скобкой, но некоторые проекты не нагружены настолько...
Опишите как Вы видите процесс работы над таким объемом сайтов?

[Sly_tom_cat]

По уму - как-то так:

Разработка в git.
Сборка релиза и автоматизированное тестирование - jenkins
Далее тестовая среда - проще на виртуалках - по инструментам затрудняюсь подсказать - но там тоже можно сильно автоматизировать, хотя и потребуются определенные усилия для наладки этого хозяйства.
После успешного тестирования заливка на рабочий сервер - ansible, capistrano.

ЗЫ "Без тестирования заливать на рабочие сервера апдейты - это преступление против человечества"  - это фраза знакомой тестировщицы.

[AndreyChursin]

По уму - как-то так:

Разработка в git.
Сборка релиза и автоматизированное тестирование - jenkins
Далее тестовая среда - проще на виртуалках - по инструментам затрудняюсь подсказать - но там тоже можно сильно автоматизировать, хотя и потребуются определенные усилия для наладки этого хозяйства.
После успешного тестирования заливка на рабочий сервер - ansible, capistrano.

ЗЫ "Без тестирования заливать на рабочие сервера апдейты - это преступление против человечества"  - это фраза знакомой тестировщицы.

Но всё это при условии разрешений со стороны сервера...
Как я понимаю, Ваш метод больше для разработки ПО, а не "мелких сайтов без ssh" или я не прав?
Да и 40 сайтов хранить в git - накладно, + не понятно как будет обновляться бд..

p.s. Да и заставить работодателя поверить, что хранить и работать с сайтами будет сложнее, будет не так уж просто... тем более, что работало же всё без меня и всй этой сложнятины...
Если можно, люди с опытом именно разработки сайтов дайте комменты!

[Punko]

AndreyChursin, я не разрабочтик  сайтов, но я деплою и поддерживаю сайты и изменения, которые делаются фрилансерами.
Именно с помощью Ansible.
Человек сделал мерж в мастер ветку гита - запустил мой, грубо говоря, скрипт(одной командой!!) и всё  - изменения, будь они маленькие или большие - и они на серваке.

[Sly_tom_cat]

Punko, это как - один налабал и оно опа сразу в работу? Не единого теста?

[Punko]

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

[Sly_tom_cat]

Punko, ну типа так - есть кому по шапке выдать... тестов это не заменяет ИМХО.

[Punko]

Sly_tom_cat, а тут уже, грубо говоря, моя хата с краю.

Обычный диалог:

-Вы считаете, что это готово в продакшн?
-да
-ок, я это выкину в продакшн.

естественно, на крупных проектах:

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

[vallentin]

я тоже за автоматизацию)

[mops1k]

По уму - как-то так:

Разработка в git.
Сборка релиза и автоматизированное тестирование - jenkins
Далее тестовая среда - проще на виртуалках - по инструментам затрудняюсь подсказать - но там тоже можно сильно автоматизировать, хотя и потребуются определенные усилия для наладки этого хозяйства.
После успешного тестирования заливка на рабочий сервер - ansible, capistrano.

ЗЫ "Без тестирования заливать на рабочие сервера апдейты - это преступление против человечества"  - это фраза знакомой тестировщицы.

Но всё это при условии разрешений со стороны сервера...
Как я понимаю, Ваш метод больше для разработки ПО, а не "мелких сайтов без ssh" или я не прав?
Да и 40 сайтов хранить в git - накладно, + не понятно как будет обновляться бд..

p.s. Да и заставить работодателя поверить, что хранить и работать с сайтами будет сложнее, будет не так уж просто... тем более, что работало же всё без меня и всй этой сложнятины...
Если можно, люди с опытом именно разработки сайтов дайте комменты!

Для открытого кода есть github, для всего остального есть gitlab с огромной кучей бесплатных приватных репозиториев, ну или заводиться свой гит сервер. Вам уже тут раз 7 сказали что вопрос решается только гитом, а вы извините, никого не хочу оскорблять как баран в закрытые ворота рогами долбитесь, мол неудобно.
Если вам удобно что затираете чужой код, тогда вам и менять ничего не надо...

Прошу прощения если получилось резко, никого не хачу обидеть =)