Как стать автором
Обновить

Комментарии 15

НЛО прилетело и опубликовало эту надпись здесь
А зачем на каждый чих коммитить и пушить? Разрабатываешь локально, с подключенными тестовыми ресурсами, когда убедился, что ок, коммитишь и пушаешь. После этого на тестовом стенде собирается ветка и её можно дать пощупать другим.
Я согласен, если есть возможность работать локально — это здорово, но в моем случае разобраться, как выгрузить проект локально так, чтобы он не отличался от тестовых стендов, потребует больше времени (особенно учитывая всю инфраструктуру), если бы был один docker-compose.yml, то было бы проще конечно.
у нас есть сервер, куда так уходит каждый коммит. Его пользуют след. люди: scrum master, product owner, UX&UI дизайнер, и я частенько, как тимлид

при том разработка идёт локально, коммит в фичу. А выгрузка на серв происходит по коммиту в девелоп.
Мой коммент был именно про «пуш на каждый чих». Когда разработчик не может увидеть результат своего труда до того как он закоммитит, запушит и дождется выкатки feature-ветки. Это слишком долго. А если еще вспомнить, что должны прогнаться тесты, то совсем грустно становится.
Кроме как зависимость опредёлённого интерфейса (АПИ), который локально не работает — в голову ничего не идёт… Возможно Вы правы, может необходимость этого связана с отсутствием «системы/процесса» разработки...?!
однако статья дельная — в закладочки…
Можно же в фич-ветке делать сколько угодно комитов (для себя), затем rebase и мердж единственного комита в локальный dev. Так в фич-ветке будет один комит. Затем фич и dev ветки пушатся на сервер и пересобирается dev стенд, который тестят scrum master, product owner, UX&UI дизайнер. Если все ок, таска закрывается и главный мерджит dev в master.
почти так и есть… это был не вопрос ;)
А… смутило «каждый» комит.
С каких пор буква 'n' стала появляться в commit hash?

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


Не уловил из статьи почему не подошёл SFTP?
удалённую машину переключил на нужный комит, локальную машину на тот же самый комит и по SFTP все изменения улетают с локальной машины на удалённую, какие недостатки?
rsync работает в режиме точечной правки, но разве в целом это что то другое? не думаю что прямо какие то мегабайты текста придётся пересылать если пользоваться SFTP.

rsync конечно изящней и когда уже есть готовое решение (например описанное в этой статье), то конечно грех не реализовать синхронизацию по rsync.
Если просто SFTP на общую папку, без смены маппингов, то при переключении предыдущая ветка перестанет существовать на тестовом стенде, часто это бывает неудобно, например, я в течение дня могу одновременно работать с 1-3 ветками, пока одну отправил на ручное тестирование, работаю в другой
Я на практике использовал SFTP для редактирования кода без репозитория, без переключения веток, видимо не знаю нюансов.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории