Подходят ли такие настройки / практика веб-разработки на рабочем месте? - PullRequest
3 голосов
/ 13 февраля 2011

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

Моя главная и, скорее всего, единственная неудовлетворенность работой связана с тем, что мы обязуемся использовать живую систему (у нас есть веб-портал, работающий на php и mysql), то есть я фиксирую код, и изменения мгновенно видны в режиме онлайн. Это не страшно для небольших или быстро обнаруживаемых ошибок. Но это большая проблема, когда появляется какая-то отвратительная ошибка, то есть в каком-то месте неправильно генерируются ссылки, и вы можете попасть на какую-то страницу с двумя разными URL-адресами (количество просмотров страниц ...), такие вещи легко пропустить в течение нескольких дней. (Или это? Может быть, я просто недостаточно осторожен?) Но я действительно стараюсь проверить все перед фиксацией, и мы также используем phpunit и selenium (тест написан тем же человеком, который пишет код после написания кода) для тестирования (хотя тестовое покрытие может быть больше).

Итак, мой вопрос: Принято ли делать коммиты напрямую в онлайновую систему при веб-разработке?

Ответы [ 5 ]

7 голосов
/ 13 февраля 2011

К сожалению, это обычная практика для многих новых медиа-агентств и стартапов (я часто видел это, и у меня горят глаза), но это совсем не лучшая практика .

Хорошопрактикой было бы иметь сервер разработки, промежуточный сайт и продуктивный / живой сайт.

3 голосов
/ 13 февраля 2011

Определенно нет!

Наиболее распространенный сценарий - иметь как минимум 3/4 среды:

  • Среда разработки: каждый разработчик вносит свои изменения и запускает своитесты на его личную среду.

  • Среда интеграции: все компоненты приложения объединены, что позволяет всем увидеть, все ли в порядке.Будьте осторожны с Большим взрывом .

  • Бета-тестовая среда: когда все исправлено и проверено на этапе интеграции, вы переходите к бета-тестированию.фаза испытаний.Если для этого нет конкретной команды, это часто делают разработчики (каждый разработчик проверяет функциональность, сделанную другими, чтобы избежать очевидных субъективных проблем).

  • Производственная среда: что использует клиент.

Это то, что я узнал из своего очень короткого опыта (5-месячная стажировка), надеюсь, этопомогает!

1 голос
/ 22 февраля 2012

Это кажется плохой практикой с первого взгляда.

Но учтите следующее.Если компания небольшая и не имеет команды тестирования или, по крайней мере, достаточного количества разработчиков, которые могут быть назначены для дополнительного тестирования кода, переданного другими разработчиками, наличие тестовой песочницы приведет к тому, что разработчик протестирует код на своем компьютере, а затем совершит коммит,Проведите ТО ЖЕ тестирование в песочнице (если тестирование является ручным, то во второй раз оно будет менее тщательным, представьте, что вы выполняете одно и то же задание вручную два раза подряд), затем перенесите изменения в производственную среду.Каковы шансы найти ошибку в песочнице, если этот разработчик не нашел ее на этой локальной машине?

Также всегда будет разница между песочницей и производственной средой.Поэтому, если код работает в «песочнице», это не гарантирует, что он будет работать в рабочей среде.

Наконец, рассмотрим стоимость обслуживания среды тестирования.У быстрорастущих проектов с небольшими командами просто не может быть этого.

Так что, если команда очень мала - предпочтение отдается участию в производстве с МНОГО локального тестирования.В противном случае копирование кода из одного места в другое и проведение одного и того же тестирования одним и тем же человеком будет слишком разочаровывающим, трудоемким и бесполезным.

Если имеются ресурсы для тестирования - вам, конечно, следует подумать о наличии дополнительной среды для тестирования.

1 голос
/ 13 февраля 2011

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

1 голос
/ 13 февраля 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...