Общая практика, если мы обнаружим проблему после развертывания веб-приложения?

Question

У меня недавно возникла проблема с тем, что мой Java-код отлично работает на моей локальной машине, однако он просто не будет работать, когда я разверну его на веб-сервере, особенно в части БД. Хуже всего то, что сервер не моя машина. Поэтому мне приходилось возвращаться и проверять версии программного обеспечения, учетные записи БД, настройки и т. Д. *

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

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

Спасибо, что поделились своим опытом.

Answer 1

Абсолютная причина номер один проблем, возникающих на производстве, но не в разработке, - Окружающая среда .

Ваш производственный компьютер, скорее всего, настроен совсем иначе, чем ваш компьютер для разработки. Вы, возможно, разрабатываете свое Java-приложение на ПК под управлением Windows, например, при развертывании на сервере под управлением Linux.

Важно попытаться разработать те же приложения и библиотеки, которые вы будете развертывать в рабочей среде. Вот краткий контрольный список:

1. Убедитесь, что версия JVM, которую вы используете в разработке, точно такая же, как на рабочей машине (java -version).
2. Убедитесь, что сервер приложений (например, Tomcat, Resin) в рабочей версии имеет ту же версию, что и вы в разработке.
3. Убедитесь, что версия базы данных, которую вы используете, в рабочей среде совпадает с версией.
4. Убедитесь, что библиотеки (например, драйвер базы данных), установленные на рабочем компьютере, имеют те же версии, что и вы в разработке.
5. Убедитесь, что у пользователя есть правильные права доступа на производственном сервере.

Конечно, вы не всегда можете получить все то же самое - многие серверы Linux теперь работают в 64-битной среде, хотя это не всегда (пока!) Со стандартными машинами для разработчиков. Но правило все еще остается в силе: если вы сможете максимально приблизить среду, вы минимизируете вероятность возникновения подобных проблем.

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

Если вы можете позволить себе промежуточный сервер, процесс развертывания должен выглядеть примерно так:

• Убедитесь, что приложение работает локально в разработке, и чтобы все модульные и функциональные тесты проходили в разработке.
• Развертывание на промежуточном сервере. Убедитесь, что все тесты пройдены.
• После успешного развертывания в производство

Answer 2

Скорее всего, вы работаете под другой учетной записью пользователя. Таким образом, среда, которую вы наследуете как разработчик, будет сильно отличаться от рабочей среды (которая, вероятно, будет очень урезанной). Ваш PATH / LD_LIBRARY_PATH (или эквиваленты Windows) будет другим. Разрешения будут изменены и т. Д. Кроме того, установленное программное обеспечение будет другим.

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

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

Answer 3

В частности, вы можете проверить все файлы конфигурации (* .xml / * .properties) в вашем приложении и убедиться, что вы не жестко программируете любые пути / переменные в своем приложении.

Вы должны поддерживать разные конфигурационные файлы для каждого env. и проверьте руководство по установке от администратора env. (если существует)

Кроме этих версий всех программ / списка зависимостей и т. Д., Как описано другими.

Answer 4

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

Answer 5

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

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

Answer 6

Одна распространенная (хотя и легко обнаруживаемая) проблема - конфликтующие библиотеки, особенно если вы используете Maven или Ivy для управления зависимостями и не проверяете все управляемые зависимости хотя бы один раз перед развертыванием.

У нас было множество несовместимых версий каркасов ведения журналов и даже Servlet / JSP API .jar: в нашей тестовой среде в несколько раз больше. Также всегда полезно проверить, что содержит папка с общими библиотеками вашего tomcat / эквивалента, у нас были некоторые конфликты классов источника данных базы данных, потому что кто-то поместил jdbc jar postgre в общую папку, и у проекта был свой jar для подключения к jdbc .

Answer 7

По моему опыту нет однозначного ответа на этот вопрос. Ниже приведены некоторые проблемы, с которыми я столкнулся.

1. Автоматические обновления не были включены на dev-сервере (windows), а включены на производственном сервере (что, в первую очередь, неправильно!). Так что одно из моих веб-приложений сломалось из-за патча.

2. На сервере производственных приложений выполнялись некоторые пакетные задания, которые изменили некоторые данные, используемые моим приложением.

3. Это не я, кто выполняет развертывание для моей компании, поэтому чаще всего люди, которые развертывают, пропускают некоторые записи реестра или добавляют неправильные записи реестра. Простой, но очень трудно обнаружить (может быть, для меня ;-)), когда я потратил часы, чтобы определить пробел в одном из значений реестра. Теперь у нас есть очень длинный выпуск документа, в котором есть все подробности обо всех серверах, используемых приложением, и есть контрольный список для «текущего выпуска», который заполняют инженеры, развертывающие приложение.

Я добавлю еще, если я что-нибудь запомню.

Answer 8

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

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