ReSQL.ru
     
powered by simpleCommunicator - 2.0.54     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Интересует совет по доступу к основному серваку разрабов в большой команде
15 сообщений из 40, страница 2 из 2
  2  все
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39899825
Minamoto
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Minamoto
Участник
alexeyvg
ther
просто проекту 15+ лет, из них 13 писалась в режиме "кто сделал, тот и накатил"
...
а с культурой разработки именно sql все печально, в свое время разработчики набирались по принципу знаешь хорошо делфи - подходишь, а селект писать как два пальца
Так проблема больше не в плохих процессах, а в отсутствии специалистов по сиквелу.

Мне кажется, это разговоры из серии - "зачем вы плохо делаете, надо делать хорошо". Понятно, что идеальный вариант - 20 профессионалов, каждый из которых уникальный специалист, не допускающий ошибок и изначально закладывающий наилучшую архитектуру под будущий рост.
К сожалению, так не бывает, все мы учимся, растем в профессии, допускаем ошибки и их исправляем.
Хорошие процессы, в т.ч. в разработке - это как раз один из способов снизить стоимость этих ошибок, отловить их на подходе и быстро поправить, не допустив на продуктивные сервера. Минус, конечно, в том, что с такими процессами любой новичок сможет разрабатывать, а поэтому любой новичок и будет, нивелируя выигрыш даже от лучших процессов)
...
Рейтинг: 0 / 0
09.12.2019, 10:57
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39899881
Гулин Федор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гулин Федор
Участник
тема интересная
имхо все таки 2 человека минимум должны иметь полный доступ к проду
на случай отпуска-болезни
кто это будет 2 DBA (по мне скорей 1 DBA + 1 Lead программер )
а накатыавть чейнжи желальтельно одному (ну или вместе)
в вашем случае - вам виднее
но по мне логичней отдать это как раз лиду ( елси он есть )
на случай если что не пошло у бизнеса - и НАДО откатывать ( у нас по кр. мере такие случаи ЧАСТЫ
когда откатывается и T-SQL и версии апликухи )
...
Рейтинг: 0 / 0
09.12.2019, 12:21
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39899895
Фотография StarikNavy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StarikNavy
Участник
все ответили верно.
пока руководство будет думать - можете предложит своим 20+ разрабам на переходный период - вести дежурство. дежурный собирает все измения, собирает их в один скрипт, тестит и накатывает на бой
...
Рейтинг: 0 / 0
09.12.2019, 12:42
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39899934
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Minamoto
alexeyvg
пропущено...
Так проблема больше не в плохих процессах, а в отсутствии специалистов по сиквелу.

Мне кажется, это разговоры из серии - "зачем вы плохо делаете, надо делать хорошо". Понятно, что идеальный вариант - 20 профессионалов, каждый из которых уникальный специалист, не допускающий ошибок и изначально закладывающий наилучшую архитектуру под будущий рост.
К сожалению, так не бывает, все мы учимся, растем в профессии, допускаем ошибки и их исправляем.
Хорошие процессы, в т.ч. в разработке - это как раз один из способов снизить стоимость этих ошибок, отловить их на подходе и быстро поправить, не допустив на продуктивные сервера. Минус, конечно, в том, что с такими процессами любой новичок сможет разрабатывать, а поэтому любой новичок и будет, нивелируя выигрыш даже от лучших процессов)
Зачем 20, они же не справятся. Если 20 профессионалов-сиквелистов будут кодить сайты или вин-приложения, получится гадость, они же в них ничего не понимают.

Достаточно одного. Или нескольких, если для них есть работа именно по сиквелу.
Пусть программисты пишут запросы, как писали, но изменения модели данных, обслуживание сервера, и постановку процесса разработки в части сиквела должен делать специалист, а не секретарши или веб-программисты.

В данном случае компания нанимает профессионалов для разработке на чём то (например, на Дельфи или ASP.NET), но почему то не наняла профессионала для сиквела.
Это же явно неправильно. Они же не нанимают сиквелистов или веб-дизайнеров для разработки сервера приложений на джаве, а наоборот почему то можно?
...
Рейтинг: 0 / 0
09.12.2019, 13:20
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900021
Minamoto
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Minamoto
Участник
alexeyvg
Minamoto
пропущено...

Мне кажется, это разговоры из серии - "зачем вы плохо делаете, надо делать хорошо". Понятно, что идеальный вариант - 20 профессионалов, каждый из которых уникальный специалист, не допускающий ошибок и изначально закладывающий наилучшую архитектуру под будущий рост.
К сожалению, так не бывает, все мы учимся, растем в профессии, допускаем ошибки и их исправляем.
Хорошие процессы, в т.ч. в разработке - это как раз один из способов снизить стоимость этих ошибок, отловить их на подходе и быстро поправить, не допустив на продуктивные сервера. Минус, конечно, в том, что с такими процессами любой новичок сможет разрабатывать, а поэтому любой новичок и будет, нивелируя выигрыш даже от лучших процессов)
Зачем 20, они же не справятся. Если 20 профессионалов-сиквелистов будут кодить сайты или вин-приложения, получится гадость, они же в них ничего не понимают.

Достаточно одного. Или нескольких, если для них есть работа именно по сиквелу.

Из начального сообщения ТС я понял, что 20 разработчиков именно по SQL. Если это всего разработчиков - тогда, конечно, специализация решает, не надо пускать фронтендщиков и бэкендщиков в базу.
...
Рейтинг: 0 / 0
09.12.2019, 14:39
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900029
ther
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ther
Участник
Minamoto
Из начального сообщения ТС я понял, что 20 разработчиков именно по SQL. Если это всего разработчиков - тогда, конечно, специализация решает, не надо пускать фронтендщиков и бэкендщиков в базу.

если бы, 20 delphi + sql. Все. Причем если к делфи предъяв почти нет, то по sql просто вагон, от непонимания как строить запросы, до огромной избыточности из за непонимания как строить запросы. Излишние индексы и тд. Меня клиент вообще не интересует, только доступ к sql серверу и рабочие правила работы с ним. Доступы, накатка и тд
...
Рейтинг: 0 / 0
09.12.2019, 14:55
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900118
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
ther
Minamoto
Из начального сообщения ТС я понял, что 20 разработчиков именно по SQL. Если это всего разработчиков - тогда, конечно, специализация решает, не надо пускать фронтендщиков и бэкендщиков в базу.

если бы, 20 delphi + sql. Все. Причем если к делфи предъяв почти нет, то по sql просто вагон, от непонимания как строить запросы, до огромной избыточности из за непонимания как строить запросы. Излишние индексы и тд. Меня клиент вообще не интересует, только доступ к sql серверу и рабочие правила работы с ним. Доступы, накатка и тд
Да, я из стартового поста понял, что из 20 разработчиков ни одного по сиквелу нет.

Вот и нужен хоть один, постарайтесь донести это до руководства.
Тем более, что проблемы не только в отсутствии правильного процесса разработки, но и в самой разработке.
Запросы писать не так сложно, там помощь сиквелиста понадобится эпизодически, а вот модель данных очень важна, ну и всё, что вы перечислили.

Конечно, разработчики-дельфисты всего этого не знают. Наверняка они нормально разрабатывают на дельфях, хранят версии исходников, делают сборки версий, тестят. Но по сиквелу у них нету навыка, надо же этим заниматься постоянно, что бы он появился.
...
Рейтинг: 0 / 0
09.12.2019, 15:55
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900480
ther
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ther
Участник
Пасиб, собрал инфу, завтра буду презентовать эту штуку. У меня остался последний вопрос. К примеру, мы ставим на каждого разраба свой сервак, разворачиваем через утилиту, которая сразу рандомит определенные данные (ЗП/финансы и тд). Таким образом у нас на каждого прогера свой сервак с "побитыми" данными. Но! приходит жалоба от пользователя, что отчет выводит неправильные данные. И что в этой колонке должно быть не 10, а 154. В настоящий момент прогер не выложит ообнову, пока значение не станет 154. Но если к основному серваку у него нет доступа, а локальные данные изменены, то, если процедура расчета сложная, он может ее править просто бесконечно. И такие вещи случаются достаточно часто, так как одним отчетом могут пользоваться разные отделы, один запросил изменения, а второй уже жалобу катает.

Посему вопрос, как это разруливается? Ибо dba только тем и будет заниматься, что косяки править
...
Рейтинг: 0 / 0
09.12.2019, 22:43
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900518
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
ther
Пасиб, собрал инфу, завтра буду презентовать эту штуку. У меня остался последний вопрос. К примеру, мы ставим на каждого разраба свой сервак, разворачиваем через утилиту, которая сразу рандомит определенные данные (ЗП/финансы и тд). Таким образом у нас на каждого прогера свой сервак с "побитыми" данными. Но! приходит жалоба от пользователя, что отчет выводит неправильные данные. И что в этой колонке должно быть не 10, а 154. В настоящий момент прогер не выложит ообнову, пока значение не станет 154. Но если к основному серваку у него нет доступа, а локальные данные изменены, то, если процедура расчета сложная, он может ее править просто бесконечно. И такие вещи случаются достаточно часто, так как одним отчетом могут пользоваться разные отделы, один запросил изменения, а второй уже жалобу катает.

Посему вопрос, как это разруливается? Ибо dba только тем и будет заниматься, что косяки править
Это не самый лучший вариант, делать каждому разработчику по серваку.

Один из классических схем: 3 уровня - дев, тест, и продакшен.

Разработчики программируют на деве, потом, когда набирается некий пакет для апдэйта, то он накатывается на тест.
При этом накатывание очередной версии на тест всегда начинается с восстановления бакапа продакшена на тест.
Т.о. тестеры тестируют то, каким будет продакшен после обновления.
Если всё нормально, этот апдэйт накатывается на продакшен.
Это получается достаточно надёжно.

При этом дев тоже иногда восстанавливается с продакшена, что бы не накапливалась большая разница.

Если разработчикам приспичило поковыряться с конкретными данными, по запросу бизнеса, то они ковыряются на тесте.

Дополнительный плюс схемы - тестируются бакапы.
...
Рейтинг: 0 / 0
10.12.2019, 00:59
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900525
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
ther
Пасиб, собрал инфу, завтра буду презентовать эту штуку. У меня остался последний вопрос. К примеру, мы ставим на каждого разраба свой сервак, разворачиваем через утилиту, которая сразу рандомит определенные данные (ЗП/финансы и тд). Таким образом у нас на каждого прогера свой сервак с "побитыми" данными. Но! приходит жалоба от пользователя, что отчет выводит неправильные данные. И что в этой колонке должно быть не 10, а 154. В настоящий момент прогер не выложит ообнову, пока значение не станет 154. Но если к основному серваку у него нет доступа, а локальные данные изменены, то, если процедура расчета сложная, он может ее править просто бесконечно. И такие вещи случаются достаточно часто, так как одним отчетом могут пользоваться разные отделы, один запросил изменения, а второй уже жалобу катает.

Посему вопрос, как это разруливается? Ибо dba только тем и будет заниматься, что косяки править

у вас должен быть тест сервер, который тестируют тестировщики. Каждый разраб, после того как у него на локальной машине все работает правильно, загружает свои изменения в master branch, тестировщики тянут эти изменения на тестовый сервер и прогоняют свои тесты, если все нормально - делается релиз в прод
Т.к. очевидно, что у вас нет ни тестеров, ни тестов, то взять и 15-летнюю легаси систему перевести на правильные рельсы быстро не получится, а на практике не получится совершенно точно. Вам нужны для начала тестеры, которые проведут массированную работу по написанию интеграционных тестов и автоматизированных тестов, это огромная работа.
Юнит тесты, если у вас вся логика в хранимках с сотнями строк и тем более не получится создать.
...
Рейтинг: 0 / 0
10.12.2019, 01:06
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900659
mnbvcx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mnbvcx
Гость
alexeyvg
Это не самый лучший вариант, делать каждому разработчику по серваку.

Один из классических схем: 3 уровня - дев, тест, и продакшен.

Разработчики программируют на деве, потом, когда набирается некий пакет для апдэйта, то он накатывается на тест.
При этом накатывание очередной версии на тест всегда начинается с восстановления бакапа продакшена на тест.
Т.о. тестеры тестируют то, каким будет продакшен после обновления.
Если всё нормально, этот апдэйт накатывается на продакшен.
Это получается достаточно надёжно.

При этом дев тоже иногда восстанавливается с продакшена, что бы не накапливалась большая разница.

Если разработчикам приспичило поковыряться с конкретными данными, по запросу бизнеса, то они ковыряются на тесте.


+1
У нас команда меньше 20 человек, но примерно так как-то и выглядит.
Один из тестовых серверов обновляется ежедневно.
...
Рейтинг: 0 / 0
10.12.2019, 10:57
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900695
Гулин Федор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гулин Федор
Участник
ther
Пасиб, собрал инфу, завтра буду презентовать эту штуку. У меня остался последний вопрос. К примеру, мы ставим на каждого разраба свой сервак, разворачиваем через утилиту, которая сразу рандомит определенные данные (ЗП/финансы и тд). Таким образом у нас на каждого прогера свой сервак с "побитыми" данными. Но! приходит жалоба от пользователя, что отчет выводит неправильные данные. И что в этой колонке должно быть не 10, а 154. В настоящий момент прогер не выложит ообнову, пока значение не станет 154. Но если к основному серваку у него нет доступа, а локальные данные изменены, то, если процедура расчета сложная, он может ее править просто бесконечно. И такие вещи случаются достаточно часто, так как одним отчетом могут пользоваться разные отделы, один запросил изменения, а второй уже жалобу катает.

Посему вопрос, как это разруливается? Ибо dba только тем и будет заниматься, что косяки править


а вот тут имхо без доступа к проду с РЕАЛЬНЫМИ данными НИКАК
т.е доступ на ЧТЕНИЕ должен быть (да на буржуйских конторах бывает и без - но это оч. большой гемор)

ps про тестеров как бы вроде и правильно в пред. постах
но имхо это НЕ реально в той ситуации что вы описали
(т.е тестовый сервак сделать вполне реально и схему дев-тест-прод
а вот набрать людей и написать тесты на проект 15 лет. давности - НЕ верю)
если хочется навести порядок именно в БД - просто надо делать через 1-2 людей (а DBA или кто-то из лидов - это уж вдиней вм )
и деплоить чейнжи как описали ( м.б через тул какой-то - может руками вести историю )
...
Рейтинг: 0 / 0
10.12.2019, 11:41
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900785
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Гулин Федор
а вот тут имхо без доступа к проду с РЕАЛЬНЫМИ данными НИКАК
"НИКАК" - слишком категорично. Для большинства задач будет достаточно копии продакшена на вчерашний день.

Гулин Федор
а вот набрать людей и написать тесты на проект 15 лет. давности - НЕ верю)
Тестер - это роль. Без тестирования они и так не выкладывают изменения, но делают это на продакшене, а в роли тестеров выступают разработчики.

И в такой ситуации тестировать не на продакшене, а на его копии - вполне реально.

Далее, вполне реально постепенно внести ещё одно изменение в процесс, нанять тестеров. Не обязательно "покрыть всё тестами к завтрашнему утру", в 15 летнем проекте, но можно привлечь профессионала, который по любому сделает лучше, чем непрофессионал.

И так постепенно менять процессы, через какое то время они будут лучше отвечать требованиям бизнеса, и соответствовать пополневшему проекту.
А то у вас какая то безысходность, раз ничего не было, то и делать ничего не надо, а надо просто махнуть рукой и всё закрыть :-)
...
Рейтинг: 0 / 0
10.12.2019, 13:30
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900907
Гулин Федор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гулин Федор
Участник
alexeyvg,
так то оно так - и по хорошему хороший тестер это очень важный персонаж ИТ процесса
я просто пишу что по разному
на тек. месте работы - только-только создается тестовый контур ( тестеров нет как класс)
частично роль выполянет один бизнес-аналитик

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

а смысл поста был прост
т.е это РАЗНЫЕ задачи

1) Тестирование (тут я кстати пас - сам бы)
2) упорядочивание процесса наката DB изменений (а вот тут мне вообщем более менее все ясно )
 они конечно связаны (по кр. мере косвенно) - но имхо НЕ на прямую

зы представить чтобы кто-то писал какие-то юнит-тесты на тек.месте работы даже не смешно (хотя я НЕ утверждаю что это хорошо - но как есть)
...
Рейтинг: 0 / 0
10.12.2019, 16:50
| Ответить | Цитировать | Написать  
Интересует совет по доступу к основному серваку разрабов в большой команде
    #39900985
mnbvcx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mnbvcx
Гость
ther

если бы, 20 delphi + sql. Все. Причем если к делфи предъяв почти нет, то по sql просто вагон, от непонимания как строить запросы, до огромной избыточности из за непонимания как строить запросы. Излишние индексы и тд. Меня клиент вообще не интересует, только доступ к sql серверу и рабочие правила работы с ним. Доступы, накатка и тд

По-хорошему, до наката в прод пуш sql-кода должен code review пройти перед мёрджем, если это не что-то тривиальное.
Ну и рефакторинг, раз это уже давно существует.
+ какие-то запросы могут даже с новым сервис-паком работать хуже.
...
Рейтинг: 0 / 0
10.12.2019, 20:01
| Ответить | Цитировать | Написать  
15 сообщений из 40, страница 2 из 2
  2  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Интересует совет по доступу к основному серваку разрабов в большой команде
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=46&gotonew=1&tid=1686815]:
 0ms
get settings:
 10ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 162ms
get topic data:
 9ms
get first new msg:
 7ms
get forum data:
 3ms
get page messages:
 55ms
get tp. blocked users:
 1ms
others: 338ms
total:  603ms
созд. / загр.: 603ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]