Как крупные и мелкие веб-разработчики проверяют свой код перед развертыванием?

Вы спрашиваете о Continuous Integration / Continuous Deployment ("CI/CD").

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

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

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

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

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

Я разработчик веб-сайта электронной коммерции, когда мы были меньше (50-75 пользователей онлайн одновременно), я просто использовал FTP, например, FileZilla для обновления файлов, которые я изменил с помощью моего последнего редактирования, это означало, что люди мои изменения будут обработаны, и сайт вообще не выйдет из строя. Для небольших правок я бы также просто подключился по ssh и вручную отредактировал файл, если это нужно было сделать быстро.

Теперь мы стали намного больше и у нас есть другие разработчики (100-200 пользователей одновременно), чтобы быть справедливым, я должен был делать это раньше, но я развертываю непосредственно из PHP-шторма/контроля версий. У меня есть рабочие ветки, и как только моя работа будет готова к развертыванию, я положу ее в главную ветку.

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

Здесь есть что рассказать, и некоторые из них основаны на мнении (чего я постараюсь избежать).

How do people write code and debug, and setup before deployment to verify that their website would function fine

Существует много способов создать локальный сайт разработки, но большинство современных подходов используют контейнеры. Наиболее популярным является Docker, который позволяет создавать реплики веб-сервера, базы данных и т. д. и запускать их локально на вашем компьютере. Вы также можете использовать виртуальные машины для создания копии вашего производственного сервера или просто установить необходимые пакеты (например, php, apache, mysql) на свой локальный компьютер.

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

Also, how would you copy over the code?

Это может показаться очень самоуверенным, поэтому я просто предложу вам разные варианты и не буду выступать за или против любого из них:

• Используйте службу, например rsync, для передачи файлов. При таком подходе у вас обычно есть промежуточный сервер, на котором вы извлекаете свой код из системы управления версиями (или скопируйте его вручную, если вы не используете контроль версий), запускаете любые сценарии сборки, такие как composer, gulp и т. д., а затем синхронизируете файлы с рабочей средой. В более крупной установке вы оборачиваете все это в сценарий, чтобы автоматизировать его.

• Если вы используете контроль версий (давайте использовать Git в качестве примера), вы также можете перенести код на рабочий сервер (вместо того, чтобы довести его до производства), запустив git pull на своем рабочем сервере. Это позволит получить все последние изменения, а затем запустить любые сценарии сборки, такие как composer, gulp и т. д.

• Существуют также инструменты для продолжения интеграции (например, Jenkins), которые облегчают большую часть работы, упомянутой выше. Вы можете настроить хуки на GitHub, чтобы ваш код автоматически создавался и развертывался при слиянии с master.

• В небольшом или личном проекте может быть проще просто использовать FTP и вручную передавать файлы.