mitri4

Исходя из вашего вопроса - "деплой" это разворот сервера с нуля до рабочего состояния.

Все зависит от количества деплоев:
1. Если вам достаточно задеплоить 1 сервак и забыть про него - проще поднять руками.
2. Если вы постоянно разворачиваете > 2 серваков - однозначно надо использовать автоматизированные инструменты.

Рассмотрим несколько популярных инструментов:
1. Ansible - на мой взгляд самый удобный инструмент для быстрой и удобноый работы с парком серверов, устанавливает весь софт и настройки на вашей VPS.
2. Docker - позволяет создать на вашей VPS еще одну виртуальную машину с заранее прописанными настройками и софтом, также его иногда используют для параллельного запуска нескольких БД / веб - серверов и т.д.
3. Также есть Puppet, Chef, Salt - ими не пользовался.

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

Тут все зависит от размеров проекта:
1. Если проект маленький / средний fabric вполне справляется с такими задачами, как подтянуть изменения из репозитория / собрать статику / перезагрузить nginx и т.д., но использовать его для разворота сервера - это тяжелая работа, которую проще делать с помощью других инструментов (описано выше). Сам я тоже использую fabric для обновления прода.
2. Если проект большой и приближается к хайлоаду - то надо использовать Continuous Integration, это позволит вам сделать автоматизированную выкладку кода на боевой сервер - к примеру, пушите коммиты в репозиторий на github, срабатывает хук, начинает работать Jenkins, идет прогон тестов, при успехе тестов обновляется прод.

Инструментов для CI много:
1. Jenkins - простой и бесплатный, с кучей расширений и прочих плюшек.
2. Travis-CI - бесплатный для опен сорс, платный для приватных проектов (69$ минимальный план).
3. Buildbot, tox - не использовал.

P.S. Я думаю, что понятие "деплой" - это выкладка изменений на боевой сервер. То, что делаете вы - создаете новый сервер, разворачиваете окружение - ближе к развороту сервера. Если так делается каждый раз, когда льются изменения на боевой сервак - надо менять workflow.

кароч рассказываю как один раз меня самого научили, когда я еще был новичком и не смыслил в вебе. итак:
1) идем на сайт лаборатории касперского
2) находим любую базу сигнатур
3) и просто берем по порядку названия сигнатур и обзываем ими наши классы
4) профит)

p.s. а самое прикольное - если этот метод использовать на фрилансе предварительно составив файл replace для себя, который к каждому такому классу будет иметь соответствующий нормальный класс - то без проблем можно отдавать верстку на проверку без скайпов тимвиверов и т.д.
даже если кинут - пускай радуются такой верстке) файл replace с нормальными классам же тока у вас будет)

Начал верстать на bootstrap

Он нужен для макетирования, не для нормальной верстки.

Mobile First у вас в принципе нет. Почитайте про наследование в CSS.

Бывает сложно верстать mobile-first, потому что нету дизайна того самого mobile, или вообще не знаешь что нужно будет делать адаптив...
Я в таком случае уже в готовой десктопной верстке "чищу" все от разметки для десктопа, заворачиваю отступы и размеры где указаны в min-width: (~ширина макета) и начинаю размечать все для 0+, выставляя ширину в браузере 320. потом для ~ 600+ (больших телефонов и планшетов) - тут зачастую нужно совсем немного правок. И вообще не выношу никуда стили в отдельные файлы, все в одном классе, то есть

.my-class {
	color: red;
	@media (min-width: 600px) {
		color: green;
	}
	@media (min-width: 1200px) {
		color: black;
	}
}

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

С pixel-perfect особо не увлекайтесь, многие дизайнеры отступы расставляют как попало. Просто проверяйте чтобы примерно совпало.

1) На сколько верным было решением использовать node.js и mongo?

Вопрос во многом холиварный. CRM это по определению много-много реляционных данных. Хранить это в любом nosql - я лично считаю очень плохой идеей. Особенно когда через полгодика пойдут change request`ы и выяснится что вещи которые в реляционке делаются за пару минут в nosql могут потребовать изменения архитектуры хранения и занять человеко-недели.

3) Сайтов у компании - масса, большая часть которых - лэндинги на чистых html с php-скриптом на почту. Все заказы ссылаются на единый gmail-ящик. Можно ли грабить эти данные из ящика, чтобы отправлять их в облако?

Можно. Но с учетом того что доставка email вообще говоря не гарантирована - завязывать один из ключевых бизнес процессов на это выглядит мягко говоря странно. По хорошему - сделать в вашей CRM, API наружу для формирования заказов и переписать все сайты для работы с ним.
* Странно что Ваш программист не может ответить на этот вопрос с закрытыми глазами

4) Какие существуют удобные облачные сервисы, которые предоставляют API для node.js?

Я рискну предположить что ЛПР где то услышал про облака и ему понравилось. На полном серьезе отдавать весь бизнес контент во внешний сервис - это надо или полным идеалистом быть, или просто не понимать о чем речь идет. Только свои железные сервера, только физическое резервирование.

5) Какова примерная стоимость подобного проекта в $ ?

Смотря где вы находитесь, насколько легально все это оформляете
В Мск приличного разработчика сейчас можно найти за 100-120 т.р. net, в регионах на 40-60 net (от региона зависит).
Сколько их нужно - без ТЗ сказать нереально, но думаю что оценка снизу это 3-4 разработчика
+тимлид 100% +project manager 100% +аналитик на старте +дизайнер по желанию +devops на аутсорсе итд

PS Без обид, но ищите грамотного CTO который это все организует. Это в любом случае длинный проект, так что можно и в штат найти человека.

Не могу ответить на все вопросы, но на мой взгляд если используете python - берите django. Он более предназначен для крупных проектов.
Node.js - более ориентирован на микросервисную архитектуру. Если умеете ее готовить - то ради бога, но целиком на ноде делать думаю не стоит. Монгу стоит использовать только в случае если вы действительно понимаете отличия РСУБД от mongo.
3) Думаю это не проблема.
4) API для облачных серверов - а там какая разница, что за язык будет? Разве что наличие уже подготовленной либы.
5) Больше 1 миллиона точно.

your_project_root/your_project_name/settings/
├── base.py
├── development.py
├── __init__.py
├── local.py
├── production.py
└── testing.py

base.py - глобальные настройки
testing.py - тестовый сервер
production.py - рабочий сервер

local.py игнорируется VCS и содержит ссылку на актуальный файл настроек + необходимые, скажем, данному конкретному разработчику коррективы, скажем доступ к его локальной СУБД:

from .testing import *
DATABASES = ...

__init__.py:
from .local import *

И всё.

Работа есть, оплачивается, в чем проблема? Это работа, а не десткий сад.
Нравится\Не нравится - это дело десятое.

но я не хочу постоянно переделывать, я хочу сделать - сдать -и на новый уйти

Не берите long term работу. Long Term как раз таки подразумевает поддержку своей работы, и заставляет делать ее так, чтобы потом не было больно переделывать.

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

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

Это надо в сказку переехать. В реальности такое бывает в 0.00001% случаев. Если заказчик не просит что-то переделать - значит его просто жаба давит платить еще. И жаба сильнее чем дискомфорт от "недоделки".

Включаем flexible SSL (не требует установки сертификата на самом сервере):

Включаем кэширование на сутки (страницы будут отдаваться из кэша, который обновляется раз в сутки):

Включаем минификацию HTML, CSS и JS (ускоряет загрузку страниц):


На счет nginx: на cloudflare уже стоит nginx, который настроен на кэширование. Нет необходимости кешировать на своем сервере. Иначе будут проблемы при разработке, придется выключать кеш и там и там. На cloudflare можно включить development mode чтобы отключить кэш на время разработки (на втором скриншоте видно эту опцию).
На счет Varnish: не имел с ним дело, поэтому могу ошибаться, но по-моему его используют когда нужно частичное кеширование динамических страниц. То есть например шапка сайта динамическая, а остальное из кеша.
Вообще эффективное использование кеша это вопрос скорее для разработчика чем админа.

Не будет смены специальности без потерь. К потерям надо готовиться. Семье надо объяснить причину смены специальности. Потери будут либо в деньгах, либо в свободном времени.

В свободное (очевидно, внерабочее) время читать, смотреть, думать и делать pet projects - в этом я не оригинален. Иллюзий по поводу программирования питать не надо. У многих разработчиков 12-14 часой рабочий день, особенно у фрилансеров: 4-6 часов покодить + время на поиск новых заказов + время на общение с старыми/новыми клиентами + время на организационную деятельность + время на маркетинг самого себя. Офисные программисты работают несколько свободнее по времени, но уверен, что многие после работы ещё вштыривают проектик для себя или шабашат по мелким заказам.

Хочу озвучить ещё четыре варианта.

1. Мне известны уже несколько случаев, когда человек уходил на сдельную работу или на 1/4 ставки или на почасовку на основном месте работы и увеличивал количество часов на изучение второй специальности. Или устраивался на новое место на почасовку или на четверть ставки для стажировки, а то и на должность джуна. Сам так делал. Очень эффективно.

2. Выходные, праздники и отпуск не для ремонта или отдыха, а для ускоренной реализации своих проектов. Я кучу людей знаю, которые работают без отпуска, включая махинации с увольнением/восстановлением, чтобы просто получить компенсацию и работать дальше. Не вижу ничего сложного в том, чтобы отпуск потратить на стажировку или самообразование. Если новая работа приносит удовольствие, то можно развернуть свои собственные мысли так, чтобы новая работа считалась отдыхом (самомотивация, аутотренинг, самогипноз - называйте как хотите). Не замечали, что 8 часов нелюбимой работы тянутся долго-долго, а 8 часов любимого занятия (хобби, увлечение) пролетают незаметно?

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

4. Попробовать совмещать должности на старом месте работы. Попросить руководителя дать несложную работу из соседнего отдела программистов. Я сам встречал маркетологов-программистов, аналитиков-программистов, менеджеров-программистов. Им просто это интересно. При этом зарплата будет прежняя, а может быть повысится - как договоритесь. Ещё можно уговорить послать на курсы переквалификации, организация оплатит и время и курсы - ничего не потеряешь.

Ещё варианты плавного перехода придумать?

Кто хочет - найдёт 1000 способов, кто не хочет - найдёт 1000 причин (Конфуций)