@vanyproduction

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

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

Очень хочу перейти на sass+compass, но я не понимаю - нужно после каждой правки компилить и заливать на сайт? Тогда нужен контроль версий, чтобы это все не сломать, а эти 2 фичи уже сильно усложнили workflow (я ща не отказываюсь от тех ништяков, которые мне дают сборщики и тд).
Есть какая-то IDE, которая будет налету интерпретировать css с фтп-сервера в sass, и после редактирования, компилить обратно в css с последующей заливкой на сервер?)
  • Вопрос задан
  • 1615 просмотров
Решения вопроса 1
nonlux
@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.
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Изучите GIT, автоматизируйте рутину через gulp/webpack/etc, прочитайте книжку про непрерывное улучшение (lean) и продолжайте улучшать свой workflow что бы отвлекающих мелочей не осталось вовсе.
Ответ написан
copist
@copist
Empower people to give
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
download?id=ufWm2fSkYEEsK5OXT4v2JzxGfn5O
Наш стек технологий на stackshare.io
Ответ написан
rajdee
@rajdee
Front-end developer
Можно использовать сборку на gulp/webpack с livereload/hotreload, в которой уже будет тестовый локальный сервер. Это значительно проще и оперативнее
Ответ написан
mrusklon
@mrusklon
Не получается? Яростно гугли!
у меня сейчас так:
grunt на нем scss и мини сервер с livereload. 2 папки src и production.
Я все действия делаю в папке src , а grunt все собирает в папку production за которой я слежу лайврилоадом.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы