Asbo

По моему откат это далеко не ежедневная операция и при необходимости должна выполняться ручками. Лучше тщательнее тестировать релиз ...

правильно организовывать "выкладку" на сервер

У каждого свои подходы. В общем случае, выделяют следующее:

Есть ветка master, в которой находится production код, есть ветка staging, в которой находятся фичи, которые нужно тестить. Есть кучи feature-бренчей, которые можно мерджить только со staging, а после того как код в стэйджинге стабилизировался, можно мерджить ветку в продакшен.

Подробнее о таком подходе можно почитать у фаулера, feature-branch. Есть еще другие методологии, типа feature-switch, а еще можно вообще не париться. Все от проекта зависит, количества разработчиков и все такое.

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

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

Главное правило – храните все файлы в гостевой системе.
Проекты с большим количеством файлов будут тормозить и в Линуксе если эти файлы хранятся на основной системе. Да и логически это более правильно, держать файлы и базы данных в одном месте.

PHPStorm умеет работать с файлами по SFTP. Если это не подходит, то для windows есть всякие проприетарные решения (платные и бесплатные) для монтирования удаленных файловых систем.

P.S. Используйте Вагрант даже если перейдете на Линукс или OS X.

плюс докера(и вагранта и т.д. - т.е. контейнеров) в том, что когда Вы создадите свой проект, клиенту можно будет отдать контейнер. в таком виде все однозначно заработает у клиента - т.к. это работало у вас. Заработавшее на OpenServer далеко не факт что заработает на хостинге, на Denwer и т.д. - начиная от путей и прав, и заканчивая версиями библиотек\настроек php. Плюс с контейнерами просто релизовать тестирование Вашего кода в разных версиях php\mysq и т.д.
т.е. если Вы только начинаете и учитесь PHP - начинать с OpenServer вполне можно. Но освоить линукс в будущем в минимуме придется.

1. вы получаете окружение близкое или идентичное к продакшену.
2. вы получаете внятную консоль/шел из коробки.
3. вы избавляетесь от массы вопросов типа "на локалке все работает, а залил на сервер и получил жопу" (или наоборот).
4. у вас появляется более лучшее понимание как на сервере все работает.

при теперешнем развитие технологий и производительности железа, нет необходимости себя ломать.
можно попробовать в виртуалке (docker/vagrant)/дуалбуте и самому для себя решить стоит или нет.

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

Докер - это двойная изоляция. Изоляция того, что лежит внутри контейнера Докера от операционной системы и изоляция операционной системы от того, что лежит внутри Докер. Изоляция подразумевает изоляцию всех файлов, портов, приоритетов.

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

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

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

Вплоть до того, что идеально написанная и оттестированная программа на реальном сервере начинает себя вести непредсказуемо.

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

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

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

До этого люди мучались, придумывали хитрые инсталяторы...

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

Может сложиться ложное впечатление, что разработчик готовит контейнеры в Докер, а потом передает их админу.
Правильная методология все же другая:

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

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

Обычно начинают с познавательного чтения

Коротко. Репозиторий живет на вашей машине. Вы привязывете его к github

git remote add  origin git://github.com/paulboone/ticgit.git

И при необходимости, выливаете изменения:
git push origin master

Я использую для локальной разработки docker. Это значительно удобнее, чем держать полноценное окружение из зоопарка разных версий php и прочих штук.
Если сайт старый, под какие-нибудь древние версии apache, php и mysql. Не проблема, - смотрю на hub, если нет, то собираю свой.
При этом спокойно можно переключить на другой проект, более современный. Например с nginx, php7 и postgresql. Предварительно выключив предыдущий контейнер.

Далее в перспективе можно спокойно кинуть контейнер на сервер и за пару минут развернуть сервис.

В общем настоятельно рекомендую попробовать docker при локальной разработке.

1. GIT не относится не посредственно окружения для вашего кода, так что его имеет смысл использовать глобальный. А вот всякие composer / php / node / gulp / yarn /... - это часть окружения для выполнения, и их лучше держать прямо в контейнере.

Ладно там PHP со своими версиями, но эти же обычно обратносовместимы и не трубуют хранения зоопарка версий.

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

Да и PhpStorm можно один раз настроить указав путь в Git, ноде, File Watchers.

Это да.

Ведь с докером мне на каждом проекте все эти минификаторы, композеры указывать заново?

Да

Действительно ли оправдано использовать Docker одному или небольшой группой?

Да. Например хотите посмотреть проект годичной давности, но обратная совместимость зависимостей вашего проекта потеряна, такое сплошь и рядом.

Возможно, мои проекты не такого уровня, но мне действительно не критично воссоздать dev и prod окружение 1 в 1.

1 в 1 никто и не создает, а вот максимально похоже по стеку технологий - вот это правильно.

Ну и пусть там на боевом крутится php 5.6, когда у меня 7.1.

В таком окружении смысла нема. Ваш код будет работать по другому, на боевом сервере и на вирутальном окружении.

А если ты разрабатываешь с нуля и не знаешь какая будет конфигурация на боевом?

Ко боевому можно предъявлять требования.

Действительно ли деплой так прост, что заменяет все фтп-заливки, jenkins'ы, git-пуллы?

Нет