Какой workflow front-end разработки у вас?

Question

[VANY]

Объясню - у меня сейчас все сводится к
1) залил основу сайта на хостинг и там его уже пишу; (сам делаю и дизайн и верстку)
2) какие-либо изменения в код вносятся через связку filezilla+sublime (портативные с относительными путями и синхронизацией в Dropbox, несколько рабочих машин и не всегда ясно за какой буду работать).

Очень хочу перейти на sass+compass, но я не понимаю - нужно после каждой правки компилить и заливать на сайт? Тогда нужен контроль версий, чтобы это все не сломать, а эти 2 фичи уже сильно усложнили workflow (я ща не отказываюсь от тех ништяков, которые мне дают сборщики и тд).
Есть какая-то IDE, которая будет налету интерпретировать css с фтп-сервера в sass, и после редактирования, компилить обратно в css с последующей заливкой на сервер?)

Comments

[VANY]

Александр А: я вижу в этом вот какие плюсы - у меня лежат iPad/iPhone и я сразу вижу что работает что нет.

[nonlux]

Если работаешь с ipan iphone через wifi в чем проблема зайти не на сайт в сети а на сайт на локальной машине?

[VANY]

nonlux: а если это надо не мне а заказчику?

[VANY]

Александр А: я все же уточню - вы сайты ж не бесплатно делаете? Если вам говорит заказчик показать ему сайт - вы ему отказываете?)

[dev2expert]

Иван Украинцев: вроде взрослый человек, а такую ересь разводите, как-то это все толсто выглядит, а если не толсто, то глупо.
Зачем на продакшене что-то править? У вас нет дев сервера, на котором можно вести разработку и показывать результат заказчику перед обновлением? Тогда заведите его и за 3$ в месяц решите эту проблему.

[VANY]

dev2expert: Что тут толстого/глупого? Вы до "продакшена" вообще не общаетесь с заказчиком после утверждения макета?
У вас никогда не было задач что-то править на продакшене? Я может не с теми людьми работаю, но довольно часто бывает "вот у нас поменялось кое-что, надо вид этой штуки поменять на другую".
По поводу dev-сервера: если он находится у вас в локальной сети - да, разработка возможна через сборщики и тд, но тогда (в моем случае) заказчик не будет иметь доступа к сайту, т.к. NAT, http-proxy.
Если же он находится на каком-то удаленном сервере, то разработка через сборщики (что я и спрашивал в самом начале), точнее ее worlflow - мне не очевиден, может поделитесь?

[dev2expert]

Иван Украинцев: речь была про разработку на живой версии сайта, ваш аргумент был в том, что иначе не показать заказчику промежуточный или конечный вариант, так для этого и используйте дев сервер, на котором у вас уже будет настроен и автоматизирован деплой. Сделали, показали, получили отмашку/оплату и обновили продакшен. К вашему набору ftp+sublime добавится еще консоль дев сервера для запуска деплоя.

[VANY]

dev2expert: с текущим инструментарием у меня вообще проблем нет.
Я хочу получить преимущества - а именно SASS.
На последнем проекте делал svg анимацию, snapsvg и vivus.js оказались тормозными и отрисовывали куда хуже, чем обычный css. А в svg около 50 элементов, для каждого писать свой transition, с префиксами для браузеров. Вот меня и "бомбануло" в сторону sass.
Но мне нравится мой workflow, когда 10-20 секунд занимает нахождение ошибки (верстка/стили в F12 хрома), скачал отредактировал в sublime+filezilla и нажал кнопку (filezilla мониторит файлы на изменение). При использовании пакетных сборщиков время исправления одной такой ошибки значительно увеличивается (в постпродакшне). Я уже не говорю о каких-то фундаментальных изменениях, которые не так уж тяжело делать на нативном css, но куда монструознее через пакетные сборщики.

Answer 1

[nonlux]

Расклад такой:

1. Возьми docker контейнер с настроенным окружением для разработки.
Это удобно если вдруг разработчик станет не один, слетит система, поменяешь рабочее место. Один раз настроил и забыл )
docker запускает:
- веб-сервер (можно nginx, можно внутри gulp, все зависит о задачи)
- livereload сервер, через gulp ( f5 нажимать каждые 3 секунды - это больно
- gulp watchers ( в ручную компилить всякую хню, запускать тесты скучно )

2. Запусти vim ( или любой твой любимый редактор)
3. пиши, бл@#ь, код:
- less, sass и прочее по мне гораздо удобнее чистого css, меньше пишешь больше кода получаешь.
- не пиши голый html, используй шаблонизатор любой какой удобнее, я пользуюсь twig, но и простой {{mustache }} подойдет
4. пользуйся git. И пользуйся им часто.
- для приветных проектов поставь gitlab
- используй gitworkflow, ну или сделай хотя бы 2 ветки: например master и prodaction (об этом позже)
5. CI
- работая ты все равно допустить кучу ошибок. Проверка синтаксиса, валидация по стандартам, тесты - это все поможет тебе не облажаться.
- если ты будешь это делать сам потеряешь кучу времени просто на то что бы запускать и проверять всю свою работу. ci сервер поможет тебе убрать эту рутину из свое жизни.
6. Кроссбраузенрость
- используй browserstack ( или аналоги) для просмотра результатов своей работы
- ну уж если нашел ошибку бери реальный браузер ( или в виртуалке) занимайся отладкой
- получение скриншотов легко подключается к ci
- а так же из коробки работает и с локальными серверами
7. Обратная связь с заказчиком
- для ветки master (да и вообще для любой другой ветки) в git ты легко с помощью ci сервера + docker можешь поднимать сайт c последними обновлениями кода
- делай это у себя и можешь не боятся, что заказчик сможет забрать твою работы и забыть заплатить
8. Деплой
- я просто использую на нужном сервере gitlab-ci-worker и получаю все аналично п.7
- но для этого использую только ветку prodaction, в которую выкладываю стабильные изменения по готовности
- просто хостинг - все, что угодно ( shell, ansilbe + ssh ) через ci server
- И да не забудь что для prodaction надо бы все ассеты по сжимать ( да, да я про ci)
9 Be happy
Выкинь рутину, и делай то что тебе нравится. Пиши код))

P.S.
Это не наставление как надо работать, не реклама инструментов. Это описание моего workflow.

Comments

[VANY]

Спасибо за подробный ответ! Определенно позаимствую.

[nonlux]

be happy

[nonlux]

цена вопроса 5$ за vps + некоторое время что бы все это развернуть

[VANY]

также вопрос сопутствующий - windows или macos? Есть возможность переметнуться, вот думаю)

[VANY]

nonlux: по поводу vps - есть synology, планирую на него пихать это дело :)

[nonlux]

1. linux ( другое по моему без вариантов)
2. Не знаю, vps надежнее, так стоит не дома )) + не нужно держать белый адрес если надо дать доступ еще кому-нибудь
3. посмотри на docker hub gitlab-образы быстро все запустишь

[VANY]

nonlux:
1) всю жизнь сидел на windows, разработка последние 2 года - там же. Помимо этого занимаюсь рекламой (пакет Adobe), виртуальными турами и фото (узкоспециализированные программы), которые не всегда на мак есть.
2) белый адрес достигается путем ddns, бесплатный - no-ip.org :)
3) по-тихоньку буду все читать)

[nonlux]

Как говорится у каждого свои путь )))

Answer 2

[Сергей Протько]

Изучите GIT, автоматизируйте рутину через gulp/webpack/etc, прочитайте книжку про непрерывное улучшение (lean) и продолжайте улучшать свой workflow что бы отвлекающих мелочей не осталось вовсе.

Comments

[sim3x]

И как https://en.wikipedia.org/wiki/Lean_manufacturing внедрить в веб разработку? Есть какие живые примеры

[Сергей Протько]

sim3x: вы слышали про канбан, скрам и прочее?

[Сергей Протько]

sim3x: https://en.wikipedia.org/wiki/Lean_software_development

Answer 3

[Павел Волынцев]

1. локально развёрнута система в виртуалке Vagrant почти такая же как demo-сервер и prod-сервер.
2. весь код отправляется на bitbacket в репозиторий git в ветку dev
3. bamboo периодически проверяет состояние ветки dev (по хуку + таймаут) и через 15 минут от последнего комита запускает юнит-тесты
4. если тесты прошли, делает merge ветки dev -> в ветку demo. Конфликтов нет.
5. deployhq по хуку определяет, что изменилась ветка demo и запускает автоматическое обновление demo-сервера. Перед обновлением (* см. ниже) делается дамп базы, пользовательский интерфейс закрывается, крон-задачи и очереди тушатся (** см. ниже). После обновления делается дамп базы, интерфейс открывается, крон-задачи и очереди восстанавливаются, выполняется рестарт кэша.
6. с демо-сервера собираются метрики скорости и делаются селениум тесты
7. когда релиз, вручную мержим dev -> prod. Конфликтов нет.
8. deployhq по хуку определяет, что изменилась ветка prod и запускает автоматическое обновление прод-сервера. Перед обновлением делается дамп базы, пользовательский интерфейс закрывается, крон-задачи и очереди тушатся. После обновления делается дамп базы, интерфейс открывается, крон-задачи и очереди восстанавливаются, выполняется рестарт кэша.

9. если хотфиксы, то восстанавливаешь у себя базу с последнего дампа, берёшь код из prod, исправляешь, комитишь в prod, затем мержишь prod -> demo -> dev

* обновление - это что?
Обновление исходных кодов (PHP, Python, JS, SCSS), компиляция и сжатие CSS, сборка и сжатие JS, обновление зависимостей, установка обновлений на базу данных.

** зачем закрывать интерфейс, тушить крон и очереди?
В проекте много всяких вещей, которые не хранятся в репозитории, а именно: CSS собранные из SCSS, модульное приложение на AngularJS с кучей зависимостей, подмодули git, пакеты для PHP (composer) - они на bamboo, на demo, на prod собираются заново. Это занимает время. Чтобы не было сбоев, выключаем всё, кроме самой сборки. На машинах разработчиков все зависимости обновляются по мере необходимости, а на CSS и JS следит gulp.

Настройка всей этой кухни заняла 2 месяца. По другим проектам - неделю максимум.

Ссылки: Bitbucket (git), Vagrant (develop), Bamboo (continuous integration), Deployhq (continuous deployment).

Ну и чуть рекламы от спонсора ;)
Icons8 15 000+ free flat style icons

Наш стек технологий на stackshare.io

Comments

[nonlux]

как контролируете изменения в бд при разработке?

[Павел Волынцев]

nonlux: Обычные миграционные файлы фреймворка Yii

[nonlux]

ясно

Answer 4

[Руслан Абдуллаев]

Можно использовать сборку на gulp/webpack с livereload/hotreload, в которой уже будет тестовый локальный сервер. Это значительно проще и оперативнее

Comments

[VANY]

А показать заказчику? А если какие-то проблемы именно на хостинге? А если вам через месяц звонят, предлагаю 2х первоначальной стоимости и изменить 20-30% сайта уже вчера - тоже будете на локальном делать?

[Руслан Абдуллаев]

Вы не смешивайте процесс разработки и "выкладки в продакшн". Вопрос стоял о workflow front-end разработки, после финальной стадии можете отдавать заказчику /заливать на хостинг

[Дмитрий Кравченко]

Иван Украинцев: я буду на локальном сначала, разумеется

[Сергей]

Иван Украинцев: Конечно на локальном. На боевом только готовый результат выкладываются. Хотя сам так делаю редко и знаю что очень пллохо

[VANY]

Руслан Абдуллаев: до выкладки в продакшн ваш заказчик сайт не видит? Я говорю не о макетах. По поводу локального сервера - вы наверное не сталкивались с интернетом в больших организациях, там кроме вас на ваш локальный сервер никто не зайдет, NAT, http-proxy (да, без s).

Answer 5

[Павел]

у меня сейчас так:
grunt на нем scss и мини сервер с livereload. 2 папки src и production.
Я все действия делаю в папке src , а grunt все собирает в папку production за которой я слежу лайврилоадом.

Comments

[VANY]

для уточнения - если вы уже отдали проект в продакшн и через неделю две вас просят изменить какие-то фундаментальные вещи - что вы делаете?

[Павел]

2 варианта: если в проекте нечего не трогали , то я просто продолжаю править src. Если что либо поправили тогда беру все файлы кладу в src , через любой редактор стилизирую минифицированный код и продолжаю править. Единственный косяк будет с scss но это уже глобальная проблема препроцесоров , а не мой конкретный случай :)