Comments 10
Это прекрасно. Особенно на фоне того как сама IBM, своим маркетингом, убивает замечательную платформу.
Новый подход нравился службе поддержки и бизнесу— потому что все легло на плечи разработчиков, а где же devops?
Некоторые проблемы так и остались нерешенными. Протестированное ПО не всегда соответствовало тому, что ставили в продуктив. Разработчик всегда мог в последний момент что-то поменять в подготовленной программе, руководствуюсь своим видением правильности работы системы— а как насчет ставить протестированные сборки?
В экстренных ситуациях даже служба поддержки может внести небольшие изменения в код и отправить исправление в продуктив, не обладая ценными знаниями о компиляции, сборке и установке ПО.— а как же кровавый ынтэрпрайз! служба поддержки вносит изменения, а эти изменения нигде не отраженны в документации и тп, а потом гадай зачем это сделали и возникают старые проблемы — Протестированное ПО не всегда соответствовало тому, что ставили в продуктив
спасибо за коммент :)
Давным давно Некоторое время назад цели у поддержки и разработки могли отличаться. Кому-то надо стабильно, а кому-то быстрее в продуктив.
Но сознание и подходы меняются. Сейчас же работаем с общими целями. Поддержка помогает скорейшему выходу продукта в среду промышленной эксплуатации, а не ставит дополнительные излишние ограничения и усложнения, но и не забывает про качество.
Старались, но поставку для «боя», готовил разработчик только после тестирования и под конкретную среду. В этот момент и могли происходить чудесные изменения.
Но теперь, как я уже писал в статье, сборка проходит все стадии и все среды. Внезапно изменить её после тестирования, практически невозможно.
Намного проще и быстрее провести её через весь процесс. Это займет от пары минут до пары часов (в зависимости от сложности ПО и кол-ва тестов).
Мелкими изменения от поддержки, это чаще всего «хот-фиксы», если разработчик в данный момент недоступен. Изменения отражаются и в хранилище кода с соответствующими комментариями, и в Jira и в artifactory и т.д. Это скорее некоторое исключение из процесса, про которое всегда узнают и аналитики и разработчики.
потому что все легло на плечи разработчиков, а где же devops?
Но сознание и подходы меняются. Сейчас же работаем с общими целями. Поддержка помогает скорейшему выходу продукта в среду промышленной эксплуатации, а не ставит дополнительные излишние ограничения и усложнения, но и не забывает про качество.
— а как насчет ставить протестированные сборки?
Старались, но поставку для «боя», готовил разработчик только после тестирования и под конкретную среду. В этот момент и могли происходить чудесные изменения.
Но теперь, как я уже писал в статье, сборка проходит все стадии и все среды. Внезапно изменить её после тестирования, практически невозможно.
Намного проще и быстрее провести её через весь процесс. Это займет от пары минут до пары часов (в зависимости от сложности ПО и кол-ва тестов).
служба поддержки вносит изменения, а эти изменения нигде не отраженны в документации и тп
Мелкими изменения от поддержки, это чаще всего «хот-фиксы», если разработчик в данный момент недоступен. Изменения отражаются и в хранилище кода с соответствующими комментариями, и в Jira и в artifactory и т.д. Это скорее некоторое исключение из процесса, про которое всегда узнают и аналитики и разработчики.
Мы вместо CL для установщиков в одном крупном банке использовали REXX — интерпретируемый встроенный язык. Сделали для себя стандартный почти всемогущий шаблон инсталлятора — и стало весьма хорошо.
То есть админам оставалось взять подписанный savf, отресторить его и запустить REXX. Ну, кроме совсем уж сложных случаев.
В другом крупном банке для сборки и деплоя частично прикрутили gradle при помощи кучи java и открытого toolbox'а. Но по моим ощущениям для разработчиков это не зверски удобно. Из того, что я видел, наша подготовка инсталлятора была проще подготовки скрипта для gradle. Но не знаю, сам не пробовал.
То есть админам оставалось взять подписанный savf, отресторить его и запустить REXX. Ну, кроме совсем уж сложных случаев.
В другом крупном банке для сборки и деплоя частично прикрутили gradle при помощи кучи java и открытого toolbox'а. Но по моим ощущениям для разработчиков это не зверски удобно. Из того, что я видел, наша подготовка инсталлятора была проще подготовки скрипта для gradle. Но не знаю, сам не пробовал.
Да, gradle java и jt400 видели на imbi meetup в этом году. Довольно интересная идея, но однозначно поднимает порог вхождения для разработчиков.
Я хотел написать инсталлятор на CL, но потом отошел от установки обновлений и как-то остыл.
А вообще у мне для своих нужд очень много на CL и даже с вызовами системного API. Слава богу возможностей CL вполне хватает разобрать бинарные результаты и юзер спейсы. А когда IBM штатно добавил вызов SQL прямо из командной строки, так вообще открылся простор для скриптования.
А вообще у мне для своих нужд очень много на CL и даже с вызовами системного API. Слава богу возможностей CL вполне хватает разобрать бинарные результаты и юзер спейсы. А когда IBM штатно добавил вызов SQL прямо из командной строки, так вообще открылся простор для скриптования.
Кстати, мы добавляем значения в User Defined Information с помощью вызова API (QLICOBJD) из CL сборщика.
Если говорить про возможность вызова системного API, то IBM тут конечно очень сильно выступил и облегчил нам жизнь. У нас в Ops написано много вспомогательных тулов на SQL (функций и хранимок) с вызовами различных системных «апишек».
Если говорить про возможность вызова системного API, то IBM тут конечно очень сильно выступил и облегчил нам жизнь. У нас в Ops написано много вспомогательных тулов на SQL (функций и хранимок) с вызовами различных системных «апишек».
Бобик жив ещё? Помнится когда я админил в Пенсионном фонде и ещё была жива OS/2 (на которой тоже есть REXX), в качестве клиента к AS/400, я операторам багоисправитель пачек документов, от работодателей написал. Та багованная досовая софтина от погромистов (это не опечатка) пенсионного фонда частенько делала дупы, в результате чего бедным женщинам приходилось глазками эти дупы выискивать и ручками удалять. А потом ещё и индексы исправлять и в заголовке правильное количество не забывать прописывать. Недавно вспомнил, что подарил этот нехитрый скрипт в коллекцию одного фаната REXX. И да. Этот артефакт ушедшей эпохи до сих пор есть в интернете. Сейчас-бы конечно, я-б вместо LineIn использовал-бы СharIn, засасывая файл целиком в память, да парсил-бы по строкам. Но тогда молодой был. ;-)
Sign up to leave a comment.
Приручаем «динозавра», или CI/CD и IBM System i