Установка обновлений, переход на новую версию

[VarankDA]

Вопрос наверно глупый, но задам!
Существуют ли методики по переходу/тестированию на новые патчи?
Поделитесь опытом кто как переходит!

[RAJAH]

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

[VarankDA]

Ну ет понятно! Вопрос в минимизации негативных последствий установки патчей.
Например:
"За месяц до сдачи индивидуальных сведений перешли на новые патчи, в результате, когда дело дошло до конвертации стажей Гал-ка отказалась стажи конвертировать. Оказывается на новых патчах сломался режим конвертации стажей сотрудников имеющих заместительство. Выяснение этого обстоятельства потребовало 3 дней. В следствие этого возникла вероятность срыва сроков по сдаче ИС (причем сроки для нашего региона отделение ПФ устанавливает отличными от законодательства (им так удобнее), и как правило самые жесткие). В ето время Главбух заметно нервничает. Отчетность конечно сдали вовремя, однако осадок остался. Сейчас Главбух крайне негативно относится к обновлениям Гал-ки."
Может кто-то имеет опыт тестирования патчей, или есть методика по переходу.

[Руслан]

Заведите тестовую Галактику и на ней проверяйте обновления...

[VarankDA]

Тестовую Гал-ку ставим, само тестирование отдаем на откуп пользователям. Понятно, что функционал на 100 % не проверить, но ответственность с себя снимаем, а тестируемые параметры юзеры определяют сами. Как правило тестирование проходит вяло, за 2 года подобной методики выявлен ток 1 случай некритичной ошибки в патчах (криво формировался поток данных для печатной формы).
Я не могу понять - как на практике использовать кучу инфы из тхт-шников, описывающих обновления в Галактике (или это утопия).

[RAJAH]

За месяц до сдачи индивидуальных сведений

Стараемся ставить патчи во время "затишья".

Сейчас Главбух крайне негативно относится к обновлениям Гал-ки

Я сам негативно к этому отношусь! Постоянно какие-то ошибки вылезают - одно лечат, другое ломают.

тестирование проходит вяло

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

как на практике использовать кучу инфы из тхт-шников

Да помощь, документацию никто не читает, а вы про описания патчей.

[maikl]

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

[edward_K]

Я бы не советовал ставить патчи без крайней на то необходимости менее чем за 2 недели до наступления критичных событий - скажем расчет ЗП, закрытие периода в бухконтуре. Я стараюсь ставить патчи после закрытия ЗП - это 10-12 числа. Следующее окно с 25 по 28. Перед сдачей отчетности лучше прогнать заранее(за месяц) - чтобы найти ошибки функционала и свои ошибки и уж точно в этот период не нужно ставить патчи, без явных на то указаний со стороны ТП. Сейчас в декабре уже нужно наичнать проверку формирования отчетности по НДФЛ - адреса , вычеты и так далее, чтобы успеть иправить свои косяки этим годом и озадачить ТП возникшими проблемами. А да - никогда не ставьте патчи в пятницу, если не планируете работать в субботу и воскресенье.

[savov]

1. Тестировать самим на тест-базе по самым критичным моментам ( обязательно!).
2. Пересобрать заранее все свои ресурсники ( старайтесь уменьшить число присоединенных отчетов или использованных стандартных фейсов).
3. Как правильно тут опытные люди говорили, ставить только тогда, когда "приспичило" ( функционал, смена законов и пр), ставить всегда после критичных работ ( расчет зп и пр).
4. Читать описания надо, стараясь понять, что из ваших ошибок, пожеланий там учтено( или нет). Но все прочитать - муторно и долго.

[VarankDA]

Предлагаю обсудить следующий тезис:
IT-шники не могут классифицировать операции на предмет "критичности", поэтому тестирование отдаем пользователям, а в качестве протокола, с них запрашиваем анкету с проверенными параметрами!
Результат:
- Наличие документально подтвержденных свидетельств о работоспособности патчей;
- Пользователи более скрупулезно относятся к тестированию, т.к. надо чем-то подтвердить.
Кто нить такой фигней страдал?

[Алексей]

раньше проверяли, сейчас просто объем слишком большой. не проверяем. разве что иногда узкие места, специфичные для нашего предприятия.
ставим патчи после закрытия числа 10-20, и смотрим что да как. обычно в первую неделю если что-то и есть, вылетает. если можем решить сами, решаем. если критичная ошибка (было один раз), откатились на старый ЕХЕ.
всё проверить невозможно.

[savov]

IT-шники не могут классифицировать операции на предмет "критичности",

Айтишники все могут. Зачастую лучше бухгалтеров и других юзеров.
Я уже на двух заводах работал с Галактикой, везде именно IT-шники все и тестили.

[n0where]

IT-шники не могут классифицировать операции на предмет "критичности",

Айтишники все могут. Зачастую лучше бухгалтеров и других юзеров.
Я уже на двух заводах работал с Галактикой, везде именно IT-шники все и тестили.

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

[maikl]

Предлагаю обсудить следующий тезис:
IT-шники не могут классифицировать операции на предмет "критичности", поэтому тестирование отдаем пользователям, а в качестве протокола, с них запрашиваем анкету с проверенными параметрами!
Результат:
- Наличие документально подтвержденных свидетельств о работоспособности патчей;
- Пользователи более скрупулезно относятся к тестированию, т.к. надо чем-то подтвердить.
Кто нить такой фигней страдал?

Мы так делаем.
Зато потом никто не скажет, ИТ-ки не проверили

[Шевцов Владимир]

Столкнулись с ситуацией когда нас очень просили очень срочно обновиться. Причем совершенно не вовремя. В итоге получили критическую ошибку. Причем откатами к старой версии не решаемую, т.к. уже БД попортилось слишком кривыми ранними патчами. Всё закончилось письмами, служебками, очными ставками и прочей ерундой.
В итоге мы написали руководящий документ по обновлениям, где зафиксировали примерно такой порядок:
1. Заявка от инициатора обновлений (если обновление плановое - инициатор ОИТ)
2. Патчи на копию системы.
3. Распоряжение по проверке. Ключевые пользователи(отделы) указываются поименно с назначением зон ответвенности.
4. Акт о выполнении проверки с подписями проверяющих.
5. Патчи на рабочую систему.

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