Ох, едрить, три года теме :) Вопрос автору, что-нибудь с тех пор на рынке вспомогателей для деплоймента новое / интересное появилось? Может быть автор уже на что-то другое перешёл, и если так, то по каким причинам?
Ну и подозреваю, что можно воткнуть в него допсценарии в разные точки, например перед пересозданием симлинки заглушить вебсерер, а после поднять обратно или зарелоадить?
Он «из коробки» поддерживает разные логические энвайроменты (когда на одной машине крутятся несколько разных версий dev / qa) или это уже забота деплой инженеров по разнесению?
Вообще интересная штука, спасибо.
Окружений никогда не хватает, факт, и бюрократия доставляет, согласен. Поэтому я и упомянул идею когда один физический oracle инстанс шарится между разными окружениям. Например CI может быть на том же инстансе где у вас уже есть DEV, для разделения схем можно использовать суффиксы / префиксы — например HR_DEV1, HR_DEV2, HR_CI — три схемы в одном инстансе которые относятся к разным энвайроментам. ДБАшники могут и не заметить чита, их лишь надо попросить аккаунтов создать, а тейблспейсы для простоты поддержки можно заюзать существующие. Придется мириться правда (возможно) с некоторым даунгрейдом перформанса, но зато «в теле такая приятная гибкость образовалась» (с) :-)
По поводу выгрузки прода, совсем не обязательно каждый раз обновлять CI из свежеиспеченного физического дампа прода. Если предположить что структура прода между релизами не меняется (исключение — если quick fix выкатываете) то дамп можно сделать сразу после релиза, и потом его использовать вплоть до следующего релиза. Здесь исхожу из предположения, что данные, их свежесть, для обкатки не так важны.
А если подумать в сторону логического дампа, который требует только SCHEMA OWNER чтобы подропать все что было и пересоздать заново, то ДБАшники точно ничего не узнают :-)
Буду с интересом следить за следующими вашими статьями, пишите!
No offence, я лишь вторю Кайту, в той части, где он говорит про должное понимание особенностей (и разницы этих особенностей) субд: это не только синтаксис, это куда более важная разница в реализации MVCC которая [потенциально] ведет к необходимости по-разному реализовывать логику самого приложения.
Видимо вы пошли по второму пути, где учитываете эти особенности, оборотной стороной этой медали миритесь с возросшей сложностью.
Что за продукт, если не секрет, к которому такие требования?
> Зачем нужна беседа в HR после собеседования с руководителем я тоже не понимаю.
В зависимости от обсуждаемых с HR вопросов. Если денежных, то это своего рода способ изоляции твоего будущего руководителя от твоей будущей зарплаты.
Извините, не удержался.
[режим простых истин on] Делая приложение независимым от СУБД вы либо теряете бенефиты, которые предлагает та или иная СУБД (перфоманс как следствие) либо, погружаетесь в условную компиляцию или уровень абстракций от СУБД, пишите много кода, чтобы ваше приложение одинаково хорошо работало с _нексколькими_ выбранными СУБД. [режим простых истин off]
Хотя, признаю, бывают (редкие) случаи когда БД испольуется как черный ящик «тупо для хранения» и к СУБД возлагается минимум специфических требований.
На текущем проекте пошли еще дальше и активно юзаем переменные окружения — по аналогии с приведенным выше, это как если бы все дефайны заполнялись из них. Это удобно, например для того, когда один application server фактически шарит между собой несколько окружений (dev, qa, uat) и нужно передавать приложениям разных окружений начальные коннективити данные (сервер, инстанс, схема) + если у вас фактически в одном инстансе крутится несколько разных окружений (dev, qa, uat). Переменные окружения в этом случае, добавляя гибкости, выполняют роль профиля, который легко подсосать и приложениям, и легко передать в деплоймент скрипт (через параметры) который развернет базу. Таких профилей создается по количеству энвайронментов, выбор происходит соурсингом соответствующего .sh файла (например удобно через менюшку в ~$APPLICATION_USER/.profile на этапе логина + shell альясы типа setdev2).
Из других deployment-related полезностей — «обкатка» в CI среде патч- и ролбек- скриптов (которыми во время релиза докатывается/откатывается prod база). Для этого настраивается отдельный энвайромент, на котором автоматом (по шедулеру, по коммиту) сначала разворачивается последний прод клон, потом применяется набор патчей для разрабатываемой новой версии, потом применяются ролбеки и снова патчи (back-and-forth, back-and-forth) — т.о. гарантируется некая повторяемость, консистентность и атомарность релиза в части изменения БД.
Предмет заметки, как мне кажется, выливается из того факта, что много людей занимающих позиции HR, к сожалению, таковыми не являются. Мне даже порой представляется, что большинство соискателей (в том числе и не самых интересных работодателю) давно об этом знают и умеют HR обходить так, чтобы к ним было меньше всего вопросов.
В этих условиях автор описал нормальный рабочий воркфлоу найма сотрудников, так оно и должно быть, так оно и бывает [иногда / в нормальных компаниях / в компаниях без HR / со слабым HR / etc ].
До школы было много общения с кружковыми БК0010-01, ДВК2М, ЕС, Спектрумами. Самый первый, по-настоящему мой — 91ый год, первый класс, родители собирают остатки обесценивающихся денег и на задышавшем капиталистическим дыханием ВДНХ покупают за безумные $1025 — 386 SX 25/33 с 4 Mb RAM, 60 MB HDD, FDD 3.5" + 5.25" и VGA монитором. Думаю в радиусе ближайших пары сотен км не было счастливее первоклашки — dos 5, qbasic, turbo pascal и куча игр, журналы «Монитор» с незабываемыми статьями. Улица и дворовые игры мне были не нужны и обошли стороной моё детство.
Где-то на медиане 90ых был первый апгрейд на P75, который гнался до 120 MHz + 8 Mb + CD 2x + SoundBlaster со встроенным нч-усилителем (тогда почти все такие были) и я вновь возглавил технологические топы домашних пк :)
Всю школьную молодость промышлял тем, что собирал пк своим друзьям, одноклассникам и даже учителям — помогая сильно сэкономить на покупке по-компонентно, тогда это было актуально. Был даже такой чит-код для получения доп. скидки у барыг митинского радиорынка — представится своим, сказав заветную фразу про профсоюз.
Когда я вижу, как результат кодогенератора допиливается руками (а иначе в 90% никак), мне всегда страшно становится от того, во что превратится код, если в модель надо будет внести изменения и перезапустить кодогенератор
Он «из коробки» поддерживает разные логические энвайроменты (когда на одной машине крутятся несколько разных версий dev / qa) или это уже забота деплой инженеров по разнесению?
Вообще интересная штука, спасибо.
По поводу выгрузки прода, совсем не обязательно каждый раз обновлять CI из свежеиспеченного физического дампа прода. Если предположить что структура прода между релизами не меняется (исключение — если quick fix выкатываете) то дамп можно сделать сразу после релиза, и потом его использовать вплоть до следующего релиза. Здесь исхожу из предположения, что данные, их свежесть, для обкатки не так важны.
А если подумать в сторону логического дампа, который требует только SCHEMA OWNER чтобы подропать все что было и пересоздать заново, то ДБАшники точно ничего не узнают :-)
Буду с интересом следить за следующими вашими статьями, пишите!
Видимо вы пошли по второму пути, где учитываете эти особенности, оборотной стороной этой медали миритесь с возросшей сложностью.
Что за продукт, если не секрет, к которому такие требования?
В зависимости от обсуждаемых с HR вопросов. Если денежных, то это своего рода способ изоляции твоего будущего руководителя от твоей будущей зарплаты.
[режим простых истин on] Делая приложение независимым от СУБД вы либо теряете бенефиты, которые предлагает та или иная СУБД (перфоманс как следствие) либо, погружаетесь в условную компиляцию или уровень абстракций от СУБД, пишите много кода, чтобы ваше приложение одинаково хорошо работало с _нексколькими_ выбранными СУБД. [режим простых истин off]
Хотя, признаю, бывают (редкие) случаи когда БД испольуется как черный ящик «тупо для хранения» и к СУБД возлагается минимум специфических требований.
На текущем проекте пошли еще дальше и активно юзаем переменные окружения — по аналогии с приведенным выше, это как если бы все дефайны заполнялись из них. Это удобно, например для того, когда один application server фактически шарит между собой несколько окружений (dev, qa, uat) и нужно передавать приложениям разных окружений начальные коннективити данные (сервер, инстанс, схема) + если у вас фактически в одном инстансе крутится несколько разных окружений (dev, qa, uat). Переменные окружения в этом случае, добавляя гибкости, выполняют роль профиля, который легко подсосать и приложениям, и легко передать в деплоймент скрипт (через параметры) который развернет базу. Таких профилей создается по количеству энвайронментов, выбор происходит соурсингом соответствующего .sh файла (например удобно через менюшку в ~$APPLICATION_USER/.profile на этапе логина + shell альясы типа setdev2).
Из других deployment-related полезностей — «обкатка» в CI среде патч- и ролбек- скриптов (которыми во время релиза докатывается/откатывается prod база). Для этого настраивается отдельный энвайромент, на котором автоматом (по шедулеру, по коммиту) сначала разворачивается последний прод клон, потом применяется набор патчей для разрабатываемой новой версии, потом применяются ролбеки и снова патчи (back-and-forth, back-and-forth) — т.о. гарантируется некая повторяемость, консистентность и атомарность релиза в части изменения БД.
В этих условиях автор описал нормальный рабочий воркфлоу найма сотрудников, так оно и должно быть, так оно и бывает [иногда / в нормальных компаниях / в компаниях без HR / со слабым HR / etc ].
Где-то на медиане 90ых был первый апгрейд на P75, который гнался до 120 MHz + 8 Mb + CD 2x + SoundBlaster со встроенным нч-усилителем (тогда почти все такие были) и я вновь возглавил технологические топы домашних пк :)
Всю школьную молодость промышлял тем, что собирал пк своим друзьям, одноклассникам и даже учителям — помогая сильно сэкономить на покупке по-компонентно, тогда это было актуально. Был даже такой чит-код для получения доп. скидки у барыг митинского радиорынка — представится своим, сказав заветную фразу про профсоюз.
основа — стандартная виндовая библиотечка
www.postgresql.org/docs/current/interactive/plpgsql-porting.html
и вот еще
wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL#Oracle
может поэтому проблемы?