суббота, 30 мая 2015 г.

Распространение ПО и другие вопросы

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

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

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

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

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

Новый стенд поднимался на виртуалке, благо, нужные дистрибутивы сохранились. Но некоторые вспомогательные программы все-таки были обновлены. Обновления, в частности, затронули программу, позволяющую работать разработчикам с БД, да и само клиентское ПО для доступа к базе тоже обновили.

Надо сказать, что в качестве БД использовалась одна из версий СУБД Oracle, а в качестве клиентского ПО - Oracle InstantClient. На момент, когда в ПО вносили последние изменения, версия ораклового InstantClient-а была 11.2.0.2, а при восстановлении установили версию 12.1.0.1. Разработчики использовали свободно распространяемую версию TOAD, которая тоже изменилась. И вот, когда стенд был готов и настала пора работать, оказалось, что несмотря на то, что TOAD видит установленный Oracle InstantClient, использовать его он не может: при открытии соединения выдается ошибка, что oci.dll не может быть загружена. То есть, в системе все настроено правильно, нужная DLL находится, но вот не загружается она, и все тут.

Первое, что пришло в голову - случайно поставили не ту версию InstantClient - машинку подняли 32-ух разрядную, может, с клиентом промахнулись и поставили 64-ех разрядный? Однако, эта версия довольно быстро была развенчана - разрядность была та, что нужно. В качестве эксперимента установили старую версию InstantClient-а. На удивление, все заработало.

Тогда я стал внимательно смотреть на то, что имеется в InstantClient-ах. Понятно, что различия есть, но больше всего мое внимание привлекли подкаталоги. В старом клиенте это были vc8 и vc9, а в новом - vc10 и vc11. Название этих каталогов натолкнуло меня на мысль, что InstantClient связан с распространяемыми библиотеками времени выполнения Microsoft Visual Studio. Судя по названию подкаталогов, старый InstantClient ожидает библиотек, как минимум, от MS Visual Studio 2008, а вот новый клиент, скорее всего, работает с библиотеками MS VS2010. Однако, самих библиотек в распространяемом пакете InstantClient-а нет.

При этом, надо отметить, что на виртуалке, используемом для стенда, установлена версия Windows XP Service Pack 3 со всеми необходимыми обновлениями. Значит, скорее всего, на нем установлен и MS Visual C++ 2008 Redistributable Package, так как он много для чего требуется, а вот MS Visual C++ 2010 Redistributable Package наверняка отсутствует. Поэтому я взял на себя смелость скачать и установить этот пакет от Microsoft.

Далее наступил волнующий момент - запуск Free TOAD, выбор подключения, подключение... все работает!

Чтобы быть абсолютно честным, я полез на сайт Oracle, почитать, что пишут там про инсталляцию и использование InstantClient-а. Кое-что там действительно пишут (в самом низу странички), но вот упоминания про MS Visual C++ Redistributable Package я там не нашел. Хотя, может, плохо искал?

Так вот, о чем вся эта история? Понятно, что Oracle распространяет свой продукт, он совершенно не должен и не обязан распространять продукт от Microsoft, но все-таки. Библиотеки времени выполнения от Microsoft присутствует в установочных пакетах большого числа программных продуктов, не думаю, что есть какие-то лицензионные или другие сложности. Я понимаю, что Oracle InstantClient распространяется без инсталлятора, его установка сводится к разархивированию, прописыванию переменных окружения и все. Но можно было хотя бы указать, что для работы необходимо, чтобы предварительно были установлены нужные пакеты от Microsoft.

Кстати, Oracle довольно часто грешит такими... неполными, скажем так, поставками. Я сталкивался с похожими проблемами при работе с данными типа SQLXML. Казалось, что у меня был полный набор для работы, но практика показала, что я был не прав - в поставку JDBC драйверов входило не все, что нужно, и пришлось искать недостающие части. Но это совсем другая история.

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

Комментариев нет:

Отправить комментарий