Василий Мажекин

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

npm canvas install -s ( Флаг сохраняет скачиваемые файлы и сохраняются обычно в users/user на основном диске по умолчанию и просто извлеките данный модуль )

положите все общее в отдельный пакет, пилите там все и расшарьте между проектами.
Пакет можно хоть как организовать - от npm и bower до своего велосипеда

Команда VOLUME нужна, чтобы изменяемые данные, появляющиеся во время жизни, хранились на хосте отдельно от файловой системы контейнера, могли быть обработаны/переиспользованы после его удаления и администрируемы через Docker API.

Как и с обычным сервером, контейнер имеет ограничения по производительности.
Так что посмотрите логи контейнера, возможно дело в конфигурации апп. сервере, возможно, в ресурсах - CPU/RAM.
В первом случае помогут настройки, во втором - можно увеличить ресурсы контейнера или поднять несколько контейнеров с loadbalancer.

504 обычно означает что кончились воркеры. Что логично при большом числе параллельных запросов

Никаких "рабочих столов" на бубунте на VPS быть не должно. openssh там уже есть и даже наверняка запущен, на винде хорошо работает XShell (бесплатно для домашнего или некоммерческого применения), есть бесплатный putty.

cp certfile.crt /etc/ssl/certs
cp certfile.key /etc/ssl/private
cd /etc/ssl/certs
ln -s certfile.crt `openssl x509 -hash -noout -in certfile.crt`.0

Оплачиваются не языки программирование.

Оплачивается умение ими пользоваться.

Есть буквально одно исключение - Cobol.
Это один из старейших языков программирования, на котором начали писать еще тогда когда ваши родители еще не родились.
Приходится иметь дело с очень древними программами, причем выполняющими весьма ответственные вещи, где высока цена ошибки (первыми, кто мог позволить себе компьютеры был очень крупный бизнес)

о наблюдениям сервиса «Мой круг» в России последние пару лет по зарплатам лидируют...

Вы неверно интерпретируйте данные.

Просто ряд языков чаще используется в недорогих простых проектах. Что не отменяет их же использование в дорогих проектах. Но искажает понятие "средняя зарплата".

Плюс недорогих проектов всегда намного больше. Что еще более искажает понятие "средняя зарплата".

Ну то есть математически-формально всё так как описано в обзоре зарплат.

Но вас же интересует, поди, сколько лично вы будете зарабатывать, если смените язык?
А ваш заработок связан вовсе не с языком - а с тем, что вы в этом случае будете и с другим работодателем работать и опыта постепенно набераетесь.

Причём если Scala и Elixir два года назад по зарплатам опережали прочие языки с сильным отрывом и за последние годы выросли по зарплате несильно, то Go и Objective-C за эти же два года совершили сильный отрыв от остальных языков и догнали Scala и Elixir

Все упомянутые нельзя назвать распространенными на простых (то бишь на дешевых) проектах.

P.S.:
Узнаю типичный страх начинающего новичка (и типичное заблуждения уже начавшего новичка, который уже успел разочароваться в том, что ему не предлагают сходу 100 500 миллионов баков в месяц, как об этом все трубят) -

"Я выучу не тот язык и карьера будет погублена"
"Я выучу тот язык и карьера пойдет вверх".

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

Важно ваше умение программировать. А это понимание/знание - алгоритмов, парадигм, концепций, паттернов.

Эти вещи из языка в язык повторяются.
Трудно выучить только первый.

Сменить язык программисту с опытом - не сложно.

1. Менеджемент по Scrum - спринты, распределение задач, планирование и т.п.
2. Конфликтология.

Есть разные варианты даже в git-flow. В вашем случае, с учётом того, что вы делаете фичи, а затем выбираете, что пойдет в релиз (не очень понятно как вы формируете спринт при этом), ветка develop вам по-сути не нужна. Ветка develop предназначена для интеграции разных фич и проверки их совместной работы, в вашем случае это откладывается до финального тестирования релиза. Такой путь даёт гибкости, но может увеличить время финального тестирования, оправдан для несложных проектов и/или проектов с действительно слабым зацеплением, но даже в этом случае требуется постоянный контроль со стороны тимлида.

второй вариант, при первом работа ведется с хотфиксами

Если используется angular, уже подразумевается, что он общается с сервером через api, лучше два разных. Если проекты не большие то как сказали выше можно и в одном.

Поделитесь опытом, какой способ вы используете для своей разработки?

Лично мы используем такой способ:
1. Есть мастер ветка, туда попадает только полностью оттестированный код (обратите внимание - не в конце какого-то спринта; не после того, как на горе рак свистнет; а после прохождения всех этапов тестирования)
2. Есть dev-ветка, ею заведует старший разработчик и по мере необходимости "подливает" туда фиче-ветки.
3. Есть много фич-веток, в которых работают отдельно взятые личности, при этом откуда они будут брать кодовую базу для доработки - их личная трагедия. Если при слиянии возникают конфликты - есть старший разработчик, если ему что-то непонятно - есть авторы кода, которых можно позвать и спросить "какого тут происходит?".

Лучшая формула работы, из моего личного опыта - это "думать головой", а не слепо следовать какому-то набору правил.

Для маленьких проектов можно в 1 папку всё кидать но тогда ты можешь запутаться в BackEnd и FrontEnd,по этому посоветовал бы отсортировать,не знаю как тебе но у меня лично глаз радуется когда не надо путать где BackEnd а где FrontEnd,если ты ещё работаешь один то можно не запариваться,но группой вы будете иногда путать где что лежит и что к чему,если файлов у вас много то лучше конечно отсортируйте, если файлов мало то страшного в этом ничего нет :)