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

Question

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

Кроме того, поскольку я еще не запустил свой веб-сайт и не проиндексировал его Google, он редко посещает его, поэтому я могу свободно загружать и тестировать все, что захочу, используя PHPStorm + FTP. Но я понимаю, что, как только я закончу свой проект и получу пользователей, я не захочу что-то менять, пока они их используют.

Как люди пишут код, отлаживают и настраивают перед развертыванием, чтобы убедиться, что их веб-сайт будет работать нормально? Кроме того, как бы вы скопировали код? Оба с большого веб-сайта (например, apple.com, cnn.com - веб-сайты, которые должны быть в режиме 24/7) по сравнению с небольшими блогами / веб-сайтами.

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Кроме того, как бы вы скопировали код?

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

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

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

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

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