Локальное тестовое окружение или удаленное?

Question

[Petr Flaks]

Здравствуйте.

До недавних пор занимался только небольшими проектами и сразу отправлял все барахло в продакшн. Теперь решил учить инструменты посерьезнее (Laravel) и, по возможности, хотелось бы освоить методы разработки и технологии, которыми ранее не пользовался. Один из таких методов - тестовое окружение, без которого, говорят, никуда.

Прикинув, как это реализовывается, пришел к выводу, что даже с каким-нибудь Vargant без танцев с бубном нормально начать работать не получится, а при переустановке ОС или смене ПК танцевать придется по новой, поэтому я решил погуглить и узнал, что иногда применяются удаленные тестовые окружения. Например, иметь версию для разработки сайта на том же хосте, где находится продакшн-версия, а также, соответственно, две базы данных: под продакшн и разработку. Доступ к версии для разработки закрыть HTTP-авторизацией или чем-нибудь посерьезнее.

Собственно, вопросы таковы:

1. Какие подводные камни у удаленного тестового окружения?
   
2. Почему вы выбираете локальное окружение вместо удаленного?
   
3. Какое окружение выбирают команды, разрабатывающие сервисы уровня Тостера?
   

Comments

[Алексей Уколов]

Что вы понимаете под тестовым окружением?

[Petr Flaks]

Алексей Уколов: допустим, есть задача прикрутить новый функционал к уже существующему работающему сайту. И вместо того, чтобы сразу прикручивать этот функционал непосредственно к сайту, который посещают пользователи, для начала проверить его работоспособность нужно в тестовом окружении, в котором находится точно такой же сайт, который посещать можете только вы. Если вдруг полезут какие-то ошибки или проблемы во время разработки дополнительного функционала, то таким образом пользователей это не заденет.

[DevMan]

terron: то что вы написали обычно называется staging'ом.
на самом деле весь процесс несколько сложнее.

Answer 1

[DevMan]

как-то так:

• сидит дев и пилит какой-то фукционал. локально у него частично или полностью поднята копия проекта для работы
  
• есть сервер CI (continuous integration), который занимается запуском автоматических тестов и сборкой проекта
  
• есть testing-сервер, на который выкатывается копия проекта для препарирования людьми из qa, техрайтерами и т.п.
  
• есть staging-сервер, на который выкатывается предрелизная версия, которая отдается на препарирование кому-то из реальных пользователей
  

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

Comments

[Petr Flaks]

Скажите, пожалуйста, а какие преимущества у локального сервера перед удаленным? Если вдруг доведется работать над проектом, над которым уже работает какая-то команда, на меня не будут смотреть как на идиота, если я буду тестировать все не на локальной машине, а на своем VPS/дедике?

[DevMan]

terron: как минимум в скорости и удобстве.

[DevMan]

terron: плюс в независимости от сети. на самом деле строгих рамок нет. я работал в компании где вся разработка велась на индивидуальных vps'ках, а рабочие компы были по сути простыми терминалами.

[Petr Flaks]

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

Но мне сильно импонирует мысль о том, что удаленный сервер один раз настроил и забыл, и можно будет безболезненно использовать на всех ПК.

[DevMan]

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

[DevMan]

terron: во времена vagrant/docker/ansible/chief/etc разворачивание любого окружения сводится к нескольким командам.
а "один раз настроил и забыл" не выйдет. ибо есть и апдейты, и разные требования (по версиям в том числе), и все такое.