|
Вопрос по организации разработки, непрерывной разработки и выкладке продукта.
|
|||
---|---|---|---|
#18+
Привет. Есть небольшая команда, разрабатывающая продукт из связки: MSSQL(бекенд) и MVC+силверлайт/неткор+ангуляр(фронтенд). По инструментам и процессам начали двигаться в сторону "как у больших". Ранее, разработка БД представляла из себя подключение к продакшену через рдп и последующей работой с кодом(процедуры, отчеты и т.д.) Сейчас завели себе учетку на битбакете и потихоньку начали переезжать фронтенд-проектами на него. Поковырял тему работы с репозиториями при разработке БД, нашел три решения: от Redgate( https://www.red-gate.com/products/sql-development/sql-source-control/), от ApexSQL( https://www.apexsql.com/sql_tools_source_control.aspx) и от devart( https://www.devart.com/dbforge/sql/source-control/). Кто-что порекомендует по удобству? Возможно существует еще что-то интересное, но не упомянутое. Так же интересует организация CI/CD. Т.к. используем кучу продуктов атлассиана, пока смотрю в сторону Bitbucket pipeline с докером( https://hub.docker.com/r/microsoft/mssql-server-linux/) но всплывают разные неприятные моменты https://community.atlassian.com/t5/Bitbucket-questions/Running-MSSQL-service-in-Bitbucket-Pipeline/qaq-p/696956 По-этому, я так понимаю, пока либо Дженкинс, либо Тимсити. Один из непонятных для меня вопросов, это разработка-отладка-выкладка при больших объемах баз. В нашем случае, порядка десяти клиентов, на каждого по четыре базы. У самого большого следующие объемы БД: 1. 4 терабайта, 2. 2.5 терабайта, 3. 100 гиагабайта 4. 8 гигабайта. ибо для фронтенда, все в разы проще. Как должен выглядеть процесс в идеальном случае? Буду признателен как за конкретные рекомендации, так и за отсылки к статьям или книгам. Спасибо. PS Изначально было принято решение, в разработке уходить от shared model к репозиториям. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.07.2018, 15:59 |
|
Вопрос по организации разработки, непрерывной разработки и выкладке продукта.
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
05.07.2018, 17:53 |
|
Вопрос по организации разработки, непрерывной разработки и выкладке продукта.
|
|||
---|---|---|---|
#18+
nemo_di, Наш основной текущий стек деплоя: GitLab + TeamCity + Octopus Deploy Очень нравится. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.07.2018, 17:55 |
|
Вопрос по организации разработки, непрерывной разработки и выкладке продукта.
|
|||
---|---|---|---|
#18+
hVostt, спасибо за ссылку и связку. Но если я правильно понимаю, в репозитории хранится только структура базы(которую в первый раз, нужно вынять из существующей боевой базы), при этом разработчику для отладки необходимо какое-то наполнение базы, да и на стендах тестировщиков тоже и для автотестов тоже что-то может понадобиться(?). Как в этом случае происходит ее наполнение? После каждого получения последней версии из репозитория, разработчик должен руками накатить тестовые данные? При этом выходит, что для этих целей, каждый день нужно вырезать актуальную часть данных с существующих баз, я правильно понимаю? Это делается какими-то инструментами или самописными скриптами? Спасибо. Вообщем разработка субд, для меня нечто новое, программные продукты как-то попроще, имхо. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2018, 15:07 |
|
Вопрос по организации разработки, непрерывной разработки и выкладке продукта.
|
|||
---|---|---|---|
#18+
nemo_diНо если я правильно понимаю, в репозитории хранится только структура базы(которую в первый раз, нужно вынять из существующей боевой базы), при этом разработчику для отладки необходимо какое-то наполнение базы, да и на стендах тестировщиков тоже и для автотестов тоже что-то может понадобиться(?). В репо должен быть код миграции базы. А в Octopus можно добавить в деплой скрипты для БД, которые выполняют наполнение, при чём разные для разных стендов, это всё гибко конфигурируется. nemo_diКак в этом случае происходит ее наполнение? После каждого получения последней версии из репозитория, разработчик должен руками накатить тестовые данные? При этом выходит, что для этих целей, каждый день нужно вырезать актуальную часть данных с существующих баз, я правильно понимаю? Это делается какими-то инструментами или самописными скриптами? Ну вообще, миграции. В самой БД ведётся табличка выполненных миграций, при накате, ищутся новые миграции, которые ещё не были выполнены и накатываеются на базу, а в БД в табличку записывается информация о выполненных миграциях. Многие ORM имеют подобную функциональность на борту. Но и самому подобный механизм реализовать не сложно. Главное, всё автоматизировать. Ничего не должно делаться ручками, иначе в чём смысл всей этой автоматизации? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2018, 09:01 |
|
Вопрос по организации разработки, непрерывной разработки и выкладке продукта.
|
|||
---|---|---|---|
#18+
nemo_di, ssdt + tfs? ну и силверлайт уже почти отжил свое ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2018, 21:20 |
|
Вопрос по организации разработки, непрерывной разработки и выкладке продукта.
|
|||
---|---|---|---|
#18+
hVostt , Спасибо за рекомендации, тоже сторонник полной автоматизации. Как я говорил ранее, опыта с организацие йразработки бд нет, но попробую поковырять детальнее. Критик , Сервелат с mvc сейчас переписывается на неткор+ангуляр. TFS ранее пробовали, но он "не зашел". ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 15:50 |
|
|
start [/forum/topic.php?fid=37&fpage=2&tid=1555280]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
29ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 137ms |
0 / 0 |