К шаблонам непосредственно она конечно не относится. Интересно, как можно было бы логику реализовать с использованием шаблонов для минимизации работы настройки в каждом проекте (asp.net и БД) и автоматизации процессов. При чем чтобы процесс работал с шабонами (особенно со вторым случаем).
Допустим есть asp.net приложение, где логика приложения описана в visual studio проекте, и загружена в репозиторий MyApp. Также есть база данных MyAppDb в котором много таблиц, хранимых процедур за разработку которого отвечают другие люди в лице sql разработчиков и хранится в своем репозитории.
Приложение MyApp использует базу данных MyAppDb для своей работы.
Кроме того есть много других приложений MyApp2(3...), баз данных типа MyAppDb2 (3...).
Иногда хранимые процедуры в одной базе данных могут тянуть данные таблиц из других баз данных.
Каким образом можно шаблонами организовать деплоймент приложений и баз данных? Возможны случаи:
1) Если есть небольшие изменения, то собирается и развертывается только проект приложения. С этим все просто
2) если есть значительные изменения которые затрагивают и приложение и базу данных с которым она работает. 2 разных репозитория должны одновременно пройти процесс build и deploy так как они зависимы. Будет плохо если приложение обновилось, а новую хранимую процедуру которая она должна использовать нет в базе данных
3) если нет изменений в приложении, а есть только доработки в самой бд
4) как организовать revert изменений если таски могут быть разными. Пример: разработчик А добавил фичу в приложение и соответственно чтобы она работала добавил новый column в таблицу бд. Вроде протестировали, все хорошо , это попало в прод. SQL Разработчик Б ,в ту же БД добавил новую хранимую процедуру для другого таска. Все также протестировали и это попало в прод. Потом обнаружилось в коде разработчика А что-то не то и изменения откатили назад. При откате назад вернулась и БД. А значит работа разработчика Б тоже пропала.
Каким образом происходит деплой изменений в БД? Например обновилась stored процедура, или новый column добавился в какую-то таблицу?
А что если изменилась stored прцедура и плюс какая-то логика в приложении? В таком случае надо деплоить изменения в обоих частей (приложение и бд) одновременно.
Каким образом отслеживается таск созданный со стороны бизнеса в тикет системе? Есть ли интеграция ее с gitlab?
Если не отключить swap, то kubeadm откажется поднимать кластер и потребует его отключения перед тем как продолжить. А с технической точки зрения, свап отключается из-за того, что при нехватке памяти (если свап включен) под будет записан на диск. При многочисленном удалении и создании подов в таком состоянии (например обновили deployment) вызовет деградацию перформанса всей вм-ки (или сервера). При выключенном свапе, сам kubelet способен обработать ситуацию когда нет памяти. Он тупо не поднимет под и в описании пода (kubectl describe pod my-pod) укажет что мало памяти. Для такого сценария ответственность за правильный scheduling пода на нужных нодах ложится на администратора (taint-ы и toleration-ы + node selector-ы, к тому же есть возможность установки ресурсных лимитов для самих подов)
My tea's gone cold I'm wondering why I got out of bed at all The morning rain clouds up my window and I can't see at all And even if I could it'd all be gray, but your picture on my wall It reminds me, that it's not so bad, it's not so bad
А можно было еще легче. Поставить вот это https://github.com/infrabot-io/infrabot и написать простой PowerShell скрипт для выполнения нужных действий, там же и сохранение данных в файл и чтение реализовать.
Схема хороша, мы также сделали у себя, но пошли еще дальше. В отличии от этой схемы, АПП серверы у нас на windows, поэтому репликация идет уровне DFSR. DB сервер один на Jira App и Confluence (пользователей обеих систем много, но DB тянет спокойно) и + reverse proxy сервер, так что юзеры напрямую к jira не подключаются. Best practice это ставить reverse proxy между юзерами и серверами jira.
На уровне MS SQL подняли кластер, условно JiraCluster, и в Availability group добавили оба бд с репликацией. Автоматический failover, отключен конечно же. В connection string обеих конфигураций добавили jiracluster. Это позволяет уже не думать о том какой ip указан, потому что при ручном failover смене primary member DB, IP адрес listener-a автоматически меняется на резервную сетку в Ad DNS. Репликация директории jira_home и conf_home гарантирует полную идентичность конфигурации и прочих файлов, соответственно проверять xml файл нет необходимости.
Сделали отдельный сенсор в мониторинге который проверяет, реально ли происходит репликация, и если нет то посылает алерт, на который мы реагируем.
Планируется ли поддержка настройки браузера с помощью групповый политик Active Directory (как в хроме)? В корпоративной среде IT безопасность не даёт ее ставить, до тех пор пока не будет возможности ставить ограничения с помощью политик.
Управляющее приложение должно быть в единственном экземпляре на замкнутый контур?
И да и нет. Зависит от случая.
Для работы, скажем, с двумя независимыми офисами потребуется 2 отдельных бота и 2 инсталляции приложения?
Да, для работы независимых офисов требуется две инсталяции приложения (сколько угодно много для любого количества офисов), но бот может быть один. Главное чтобы команды нигде не были идентичными, а то инсталяции с одинаковыми командами будут выполнять одно и то же.
А если записать изначальную информацию куда-то в файл до выполнения каждого шага, будет ли возможность этой записанной информацией получить обратно исходный текст? То есть пойти наоборот?
Согласен, но это не отменяет того факта, что купленный товар не должен быть однарозовым. Прослужил год — выкидывай — покупай новый. Он должен быть качественным и служить долго, тем более за такие деньги, и естественно не без тех обслуживания.
"сказать начальнику, на чём вы его вертели" и "прожить полгода на пособие по безработице"
Где второе вытекает из первого
К шаблонам непосредственно она конечно не относится. Интересно, как можно было бы логику реализовать с использованием шаблонов для минимизации работы настройки в каждом проекте (asp.net и БД) и автоматизации процессов. При чем чтобы процесс работал с шабонами (особенно со вторым случаем).
можете по подробнее по поводу миграций? где я могу посмотреть\прочитать об этом?
Допустим есть asp.net приложение, где логика приложения описана в visual studio проекте, и загружена в репозиторий MyApp. Также есть база данных MyAppDb в котором много таблиц, хранимых процедур за разработку которого отвечают другие люди в лице sql разработчиков и хранится в своем репозитории.
Приложение MyApp использует базу данных MyAppDb для своей работы.
Кроме того есть много других приложений MyApp2(3...), баз данных типа MyAppDb2 (3...).
Иногда хранимые процедуры в одной базе данных могут тянуть данные таблиц из других баз данных.
Каким образом можно шаблонами организовать деплоймент приложений и баз данных? Возможны случаи:
1) Если есть небольшие изменения, то собирается и развертывается только проект приложения. С этим все просто
2) если есть значительные изменения которые затрагивают и приложение и базу данных с которым она работает. 2 разных репозитория должны одновременно пройти процесс build и deploy так как они зависимы. Будет плохо если приложение обновилось, а новую хранимую процедуру которая она должна использовать нет в базе данных
3) если нет изменений в приложении, а есть только доработки в самой бд
4) как организовать revert изменений если таски могут быть разными. Пример: разработчик А добавил фичу в приложение и соответственно чтобы она работала добавил новый column в таблицу бд. Вроде протестировали, все хорошо , это попало в прод. SQL Разработчик Б ,в ту же БД добавил новую хранимую процедуру для другого таска. Все также протестировали и это попало в прод. Потом обнаружилось в коде разработчика А что-то не то и изменения откатили назад. При откате назад вернулась и БД. А значит работа разработчика Б тоже пропала.
Каким образом происходит деплой изменений в БД? Например обновилась stored процедура, или новый column добавился в какую-то таблицу?
А что если изменилась stored прцедура и плюс какая-то логика в приложении? В таком случае надо деплоить изменения в обоих частей (приложение и бд) одновременно.
Каким образом отслеживается таск созданный со стороны бизнеса в тикет системе? Есть ли интеграция ее с gitlab?
Если не отключить swap, то kubeadm откажется поднимать кластер и потребует его отключения перед тем как продолжить. А с технической точки зрения, свап отключается из-за того, что при нехватке памяти (если свап включен) под будет записан на диск. При многочисленном удалении и создании подов в таком состоянии (например обновили deployment) вызовет деградацию перформанса всей вм-ки (или сервера). При выключенном свапе, сам kubelet способен обработать ситуацию когда нет памяти. Он тупо не поднимет под и в описании пода (kubectl describe pod my-pod) укажет что мало памяти. Для такого сценария ответственность за правильный scheduling пода на нужных нодах ложится на администратора (taint-ы и toleration-ы + node selector-ы, к тому же есть возможность установки ресурсных лимитов для самих подов)
Часто крутится
My tea's gone cold I'm wondering why I got out of bed at all
The morning rain clouds up my window and I can't see at all
And even if I could it'd all be gray, but your picture on my wall
It reminds me, that it's not so bad, it's not so bad
"Было очень интересно но я ничего не понял" ©
Да
Ветка комментариев выше напоминает реддит. Но я перепроверил. Фильм точно называется "Голая правда"
А можно было еще легче. Поставить вот это https://github.com/infrabot-io/infrabot и написать простой PowerShell скрипт для выполнения нужных действий, там же и сохранение данных в файл и чтение реализовать.
Схема хороша, мы также сделали у себя, но пошли еще дальше. В отличии от этой схемы, АПП серверы у нас на windows, поэтому репликация идет уровне DFSR. DB сервер один на Jira App и Confluence (пользователей обеих систем много, но DB тянет спокойно) и + reverse proxy сервер, так что юзеры напрямую к jira не подключаются. Best practice это ставить reverse proxy между юзерами и серверами jira.
На уровне MS SQL подняли кластер, условно JiraCluster, и в Availability group добавили оба бд с репликацией. Автоматический failover, отключен конечно же. В connection string обеих конфигураций добавили jiracluster. Это позволяет уже не думать о том какой ip указан, потому что при ручном failover смене primary member DB, IP адрес listener-a автоматически меняется на резервную сетку в Ad DNS. Репликация директории jira_home и conf_home гарантирует полную идентичность конфигурации и прочих файлов, соответственно проверять xml файл нет необходимости.
Сделали отдельный сенсор в мониторинге который проверяет, реально ли происходит репликация, и если нет то посылает алерт, на который мы реагируем.
Это тоже неплоха ModernWpf
Планируется ли поддержка настройки браузера с помощью групповый политик Active Directory (как в хроме)? В корпоративной среде IT безопасность не даёт ее ставить, до тех пор пока не будет возможности ставить ограничения с помощью политик.
Не бывает такого чтобы Apple разрешила просто вот так. Это многомиллиардный бизнес. 100% где-то есть подвох и подводные камни
И да и нет. Зависит от случая.
Да, для работы независимых офисов требуется две инсталяции приложения (сколько угодно много для любого количества офисов), но бот может быть один. Главное чтобы команды нигде не были идентичными, а то инсталяции с одинаковыми командами будут выполнять одно и то же.
А Crysis потянет?
А если записать изначальную информацию куда-то в файл до выполнения каждого шага, будет ли возможность этой записанной информацией получить обратно исходный текст? То есть пойти наоборот?
Согласен, но это не отменяет того факта, что купленный товар не должен быть однарозовым. Прослужил год — выкидывай — покупай новый. Он должен быть качественным и служить долго, тем более за такие деньги, и естественно не без тех обслуживания.