Как предоставить доступ разработчику ограничив привилегии, чтобы не потер лишнего

ты спрашиваешь, как на проде избежать ошибок разработчика? серьезно?

Могут быть проблемы у него, если права урежешь. Лучше пусть он пишет в специально созданной песочнице, которая будет бэкапиться каждую ночь с версиями. Если что то сотрет, то можно восстановить обратно.

Там 46 гигов бекапить придется. Каждая ночь - это 30*46 = 1+ Тб бекапов, овердофига.

Есть статьи с лучшими практиками по данному вопросу?

Как можно подойти к этому?

У разработчика не должно быть доступа. Это и есть лучшая практика.

Есть статья - халатность, загугли.

Есть статьи с лучшими практиками по данному вопросу?

Попросить разработчика собирать deb пакеты, или на худой конец docker.

Слышал и настраивал CI/CD. Есть ли другие пути кроме как: - завести гитрепозиторий на гитлабе - создать staging live субдомены - опкладывать все х...ми тестами - настраивать билдхуки, пайплайны.

Может быть есть свой путь? Простой, как железная дорога?

Keep calm and deploy to production?

Желательно одной кнопкой «сделать все красиво». :)

Делай икрементальные... А так вы его на месяц нанимаете?

Про очевидный докер уже сказали. На крайний случай — выдели ему отдельного пользователя. По желанию можешь загнать его в убогий и дырявый lshell (как защита от дурака — в принципе, сгодится).

На всякий случай уточню:

На сервере крутится только один сайт на PHP + MySQL + uploads

На этом сервере есть что-то еще? Или он исключительно для этого сайта?

Есть три кандидатуры, но выбран будет только один. Как пойдет. Если пойдет хорошо, может год+ постоянно нужно что-то допиливать. Если не пойдет - давай досвидания.

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

Есть все под этот сайт. Там почтовый сервер есть, например, который работает как релей для рассылок всяких.

Ничего другого, все под один проект.

появится возможность слития

И ты всё равно хочешь дать ему доступ?

Не хочу ничего, мне фиолетово. Меня волнует, чтобы данные не грохнули.

Хочет начальник - допилить его сайт.

О боже, 46 гигов! Это же в два раза больше чем весь мой диск в 2001 году!

git + CI/DI

В энтерпрайзе для этого делают несколько уровней ролаута, например prod, preprod и dev, и все выкатывания новых релизов происходят последовательно, от dev до prod. Девелоперы сначала сами( или посредством CI) выкатывают на dev, затем админы на preprod, где уже овнеры продуктов тестируют фичи, а потом уже админы на прод, в этом случае developers могут не иметь доступа к данным на prod, на pre-prod и dev не актуальные слепки базы.

Самое простое решение - развернуть докер на хост машине. Веб-сервер в докере, база на хосте (естественно, не давать рут пользователя). Всё это бэкапится с выгрузкой в несколько независимых хранилищ и никаких проблем в случае чего. Для удобств разработчика пробросить порт ssh и всё, пусть себе работает.

git init

«разработчика» точно не надо пускать на production. копия сайта с минимум данных (лучше левых тестовых) в db - это единственный путь. как я понимаю, код сайта ты не держишь в системе контроля версий? это очень большая проблема и ее надо срочно исправить. поставь gitolite. потом сделаешь ветку специально для разработчика с которой он будет работать. из этой ветки будешь по хуку или, что проще, по крону, pull-ить из этой ветки в тестовый сервер. Если же разработчик не умеет пользоваться git-ом, то с ним точно не стоит сотрудничать.

git init

+Многократно!

Никак. Разработчик разработает бэкдор если ему будет это нужно. Делай бэкапы.

Никак

Плюсую.

омг никак.

Разраб не должен иметь доступа на прод.

Вот ценная пищая для ума! Надо почитать!

У меня на простом проекте сделано так поставлен gitosis на сервер и хуком post-receive обновляются данные после того как разработчик залил код. При этом у него нет возможности зайти на сервер и вся работа с сервером происходит через git.

Тут вот какое дело - чтобы разраб случайно (а это очень вероятно) не грохнул твой сервер с данными придумано использовать тестовый сервер, с которым можно делать что угодно и 46 Гб это смешно в 2019. А вот если разраб специально хочет получить доступ на сервер, то только нанимать других разрабов на аудит кода, но не факт что поможет, если первый разраб старался сделать незаметный бэкдор.

Плюсану:

то только нанимать других разрабов на аудит кода, но не факт что поможет

И дополню: и аудит может оказаться дороже чем сделать заново.

Тут есть нюансы:

если первый разраб старался сделать незаметный бэкдор

не всегда это может быть специально, на момент разработки может оставить «некую лазейку» для лучшей отладки. Вот она и останется.
В таких ситуациях скорее играет роль человеческого фактора. Например нормальный разраб, с ним попрощались, не обидели, да и нафиг ему уперлась ваша система. Забыли и забили. Репутация дороже.
Или, нормальный разраб, с ним попрощались, не сильно обидели, но так же «Забыли и забили. Репутация дороже.»
Или «не нормальный разраб», которого уже двадцать раз кидали, он и будет вставлять бэкдоры во все проекты.
2ТС Я все это к тому, если вы по «жесткому» расходитесь с разрабом, потенциально готовьтесь к тому что он в последствии может и вам тем же ответить.
И наоборот, сделал работу, получил нормальную «денешку», в последствии за мелкие доработки или небольшую «денешку» возьмет или вообще бесплатно сделает.