Олег Кольжанов

Если тимлид не ставил задач по подключению композера и настройки тестов, то получается, что вместо реальных задач вы занимались самодеятельностью и потратили на это ресурсы компании (свое рабочее время).
Junior-вакансия это прощает, но если хотите работать в команде, нужно понимать, что в работе важен результат, а не самолюбование.
Кроме того, исходя из того, что проект старый, высок риск того, что вы подключив композер что-то сломали. Например, кто-то когда-то "пофиксил" код в копипастенной библиотеке (как бы это дико не звучало), а вы выкачали ее исходную версию из репозитория и т.д. - моментов, на самом деле много.
Может это разовая задача по внешнему проекту на 3 рубля и какой смысл в ней городить огород, если ее нужно сделать за пару часов, отдать клиенту и забыть.
Конечно, тимлид хоть и динозавр, но будет обоснованно не доволен. Странно, что он не контролировал ход работы - такую самодеятельность в процессе работы нужно пресекать на корню.

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

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

Скажу как руководитель команды разработчиков.
1. Развивайтесь.
Чем больше вы приносите пользы, тем более ценным сотрудником вы будете.
Развивайтесь как специалист, работайте продуктивно, будьте заинтересованным и смотивированным сотрудником не на словах, а на деле. Станьте лучшим специалистом в вашей компании.
2. Дайте понять, что вы хотите получать больше - это, как ни странно звучит, не всегда очевидно, особенно, когда сотрудник хорошо работает.
3. Если компания вам нравится и вы видите в ней перспективу - помогайте компании и ждите. Это длинный путь, но обязательно окупится.
Если переросли компанию и не видите перспектив, то став хорошим специалистом вы всегда сможете устроиться в другую, более успешную. Хороших специалистов сейчас отрывают с руками.

Как вариант - на машине (в контейнере), которая будет коннектиться к продакшен машине сгенерить (для пользователя, под который выполняет cap deploy) ключи и закинуть ключ на продакшен через ssh-copy-id.
Но, возможно, лучше приложение завернуть в контейнеры докер и деплоить через докер registry вместо capistrano.

Права в докере - одно из больных мест.
Универсального решения нет, ручных решений множество.
Как вариант: пробрасываем UID и GID текущего пользователя в контейнер, в Dockerfile создаем пользователя с этими UID и GID и всем файлам проекта меняем владельца на этого пользователя.

Сам еще не пользовался, но насколько знаю, делается через external-network:

В том сервисе первой сборки, из которого нужен коннект к сети из другой сборки прописываете соответствующий network из второй сборки, а в во второй сборке network'е, к которому коннектитесь прописываете параметр: external: true

Например:

# first/docker-compose.yml
version: '2'
services:
  first:
    ...
    networks:
      - network1
networks:
  network1:
    driver: bridge
...

# second/docker-compose.yml
version: '2'
services:
  second:
    ...
    networks:
      - first_network1
networks:
  first_network1:
    external: true

После этого можно обращаться к из одного сервиса к другому - из first делать ping second