Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Контроль версий на сервере и организация отладки

Контроль версий на сервере и организация отладки

Поделиться

Страницы: 1 2 Следующая

tacПостоялецwww29 июля 20172:26#0
Если делать прилично, то чтобы игроки могли играть на старой версии и им не мешала бы идущая одновременно разработка новой версии, разработчику нельзя менять ничего на рабочем сервере. Нужно сервера раздвоить и иметь рабочий сервер и сервер для отладки, и при выпуске версии обновлять рабочий сервер целиком.

Вопрос в том как это все делать по одному щелчку.

Рассмотрим, чем будут отличаться рабочий и отладочный сервер. Сервер состоит из 1) базы данных с таблицами и хранимыми процедурами, , 2) условно веб-сайта /у меня asp.net/ , который ответственный за форматы трафика 3) +на стороне клиента -  клиентском api , которое обращается к веб сайту

Все это и рабочий и отладочный сервер находятся на другой машине чем компьютер разработчика, но в одной локальной сети. Частенько требуется запустить веб-сайт под дебагом на localhost, но обращаться к все той же отладочной базе.
Итого, вот список изменений что может меняться
1. Строка расположения веб сайта - напр., cyberrise.eu, cyberrise.eu/beta, localhost
2. обращение к БД, разные строки подключения

все это можно свести к одному параметру типа ReliaseMode = 1,2,3 /рабочий выпуск/отладка/веб-сайт под дебагом/.. и нужные изменения оставить в коде, параметр вынести  в .ini на стороне клиента и в ручную менять только этот параметр, причем организовать так чтобы он влиял только для debug версии

Тогда можно написать програму обновления версии сервера, она должна забэкапить новую версию базы, удалить рабочую, развернуть на рабочей из бэкапа, тоже самое для веб- сайта копируя файлы

ах да, самое сложное забыл разворачивать из бэкапа нельзя таблицы, будет потерен прогресс игры и новые юзеры - устойчивое решение не придумал пока /кто в курсе по ms sql , подскажите команду востановления из бэкапа на рабочую базу с учетом что версии разошлись/

Но может я изобретаю велосипед и есть какая нить шняга, это реализующая ?? ну типа как контроль версий, типа утилита разворачивания новой версии? т.е. меня интересует как эти задачи делают по взрослому? неужели ручками?

upd. похоже миграцию базы сделать автоматом почти не реально

Правка: 29 июля 2017 9:54

kiparПостоялецwww29 июля 201710:45#1
tac
> она должна забэкапить новую версию базы, удалить рабочую, развернуть на рабочей
> из бэкапа, тоже самое для веб- сайта копируя файлы
не понял этот пункт. Если в бета версии изменилась структура бд и надо выкатить эти изменения на рабочую, то зачем разворачивание из бекапов? В asp.net же есть миграции.
ТатаринПостоялецwww29 июля 201711:21#2
когда ты один - ручками все делать не так сложно, раньше  в команде через git на серверах обновляли кодовую базу и готовили специальные скрипты для БД, которые администратор запускал, своего рода патчи, добавил новый предмет подготовь скрипт, новая таблица скрипт и так далее, скрипты также комитились в репозиторий, новая правка новый скрипт.
9К720Участникwww29 июля 201712:37#3
tac
> Но может я изобретаю велосипед и есть какая нить шняга, это реализующая ?? ну
> типа как контроль версий, типа утилита разворачивания новой версии? т.е. меня
> интересует как эти задачи делают по взрослому? неужели ручками?
Базы надо держать на машинах разработчиков, у каждого своя
Для контроля версий есть liquidbase, flyway

tac
> Частенько требуется запустить веб-сайт под дебагом на localhost, но обращаться
> к все той же отладочной базе.
Не надо так делать.

tac
> Тогда можно написать програму обновления версии сервера,
Есть готовые средства развертывания и деплоя. Тысячи их.

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

tac
> будет потерен прогресс игры и новые юзеры
Не будет. Останавливай сервер перед деплоем. 24-7 вы не сделаете с вашим опытом, это требует других подходов как к процедуре развертывания системы, так и к наложению некоторых ограничений на возможные изменения в коде и реализацию фич.

Я заводил тут как-то тему, про контроль версий, лет 7 назад наверное. Оглядываясь на прошлый опыт, могу сказать следующее.
1. Дойти самому по книжкам очень тяжело. Учитывая, что у тебя опыт нулевой, то невозможно сейчас.
2. Все что ты выучишь сам, будет весьма бесполезно и уныло. Иди работать туда, где будут люди намного опытнее тебя. Хотя бы поначалу.

9К720Участникwww29 июля 201712:41#4
Татарин
> добавил новый предмет подготовь скрипт, новая таблица скрипт и так далее,
> скрипты также комитились в репозиторий, новая правка новый скрипт.
Из своего опыта могу сказать, что это трудно понять самому с нуля. Особенно, когда ты кодишь один. Или когда не один, а с толпой таких же нубов, для которых это открытие. Тяжело принять, что не закомиченный SQL скрипт, который вставляет запись в таблицу-справочник это то же самое что и не написанный код, что это равноправные вещи.  Хрена ли там  - а, ну да, забыл скрипт закомитить, щас руками вставлю.
ТатаринПостоялецwww29 июля 201721:47#5
9К720
Я бы не сказал что это какая то большая польза для проекта, для новичков это нужно чтобы они привыкли к дисциплине кода ну и чтобы найти виновного, такая муштра на внимательность, ну и чтобы лид видел всю деятельность.
для человека с опытом такие патчи не несут пользы, откатить такой скрипт нельзя его присутствие в репозитории бесмыслено, а порой такие патчи занимают уйму времени потому что начинаешь снабжать их комментариями выравнивать строчки)))
Свои проекты максимум я что делаю это бекаплю и все, все остальное это творческий бардак)
tacПостоялецwww29 июля 201721:52#6
9К720
> Иди работать туда, где будут люди намного опытнее тебя
ну с этим у меня все в порядке, работаю с такими мамонтами, что многим не снилось :)

9К720
> Тяжело принять, что не закомиченный SQL скрипт
Татарин
> готовили специальные скрипты для БД

вот так и делают работающие со мной мамонты, ну и я собственно на работе ... но это голяк - не удобно тысячу раз

суть поста

tac
> Вопрос в том как это все делать по одному щелчку.

а предлагаемое много хуже

ТатаринПостоялецwww29 июля 201721:56#7
tac
ну да когда придумаешь такое нам тоже сообщить не забудь.
tacПостоялецwww29 июля 201722:51#8
Татарин
> ну да когда придумаешь такое нам тоже сообщить не забудь
ночью пришла такая идея ... (ну вы в курсе, что ночные идеи, надо еще раз прокрутить :) - давайте вместе )

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

Поэтому имеем одну - рабочую. Изменения в таблицах можно делать сразу, в 90% случаев это никак не скажется на роботоспособности приложения - если конечно не выделываться и не переименовывать старые поля. (впрочем, и тут можно найти выход и сделать view на таблицу, для поддержки старых названий, а при выпуске версии переименовать ) Остается тогда только следить за версиями хранимых процедур и функций. Думаю надо завести такое правило разработки, новую версию процедуры/функции не изменять в старой версии, а создавать новую как копию и потом менять и записывать с именем с суффиксом _new.

завести за правило в sql процедуре/функции вначале проверять текущий режим ReleaseMode - и если = 1,2 и есть процедура с суффиксом _new делать переадресацию (полиморфизм) на процедуру с суффиксом _new

теперь вместо миграции - надо при выпуске версии, просто сделать бэкап (ну так на всякий при авто действии), удалить старые процедуры, и убрать суффиксы из названий


вообще то вроде гениально :) - хвалите, критикуйте

всяко лучше, чем спускаться на уровень скриптов с контролем версий (этот подход оправдан лишь тогда, когда ты продаешь свое ПО многим, а не тогда как в нашем случае мы единственные (как фирма) разрабатывающие/обновляющие свое же ПО - сервер к нашей игре )

Правка: 30 июля 2017 2:35

tacПостоялецwww30 июля 20172:10#9
9К720
> Я заводил тут как-то тему, про контроль версий, лет 7 назад наверное
ты зарегистрирован только 5 лет как :)
ТатаринПостоялецwww30 июля 201711:23#10
tac
я с mysql или mssql уже не работаю да и ограничивать их ради того чтобы тебе было удобно это плохо, богатый функционал а ты его на ветер кидаешь.
У меня свой тип БД а если надо то REDIS или couchdb использую, так что твой способ мимо меня проходит.
tacПостоялецwww30 июля 201720:24#11
Татарин
> способ мимо меня проходит
ну, я не растроился ;)
tacПостоялецwww30 июля 201720:25#12
Татарин
> богатый функционал а ты его на ветер кидаешь
чем ? общие слова
tacПостоялецwww30 июля 201720:28#13
Татарин
> свой тип БД а если надо то REDIS или couchdb использую
это даже бд не назовешь - детские поделки
ТатаринПостоялецwww30 июля 201721:08#14
tac
ты потратишь время создавая свою систему, а она не даст профита, будет ломаться всплывут подводные камни, sql запросы существуют туеву кучу лет но воз и ныне там, конечно дерзай, шансы малы но они есть, но если начинать великое дело то сделай бд которая будет совместима с git чтобы и код комитить и откатывать и ветки вести - за такую технологию многие бы сказали спасибо, будет она построена на базе sql или rest или еще какой не суть важно.

Страницы: 1 2 Следующая

/ Форум / Программирование игр / Сеть

2001—2017 © GameDev.ru — Разработка игр