Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Одновременная разработка - лучший способ

Одновременная разработка - лучший способ
Я
   letarch
 
05.03.20 - 16:28
Здравствуйте.
Есть конфигурация УТ и два программиста, что её разрабатывают используя хранилище. У каждого программиста есть копия боевой конфы УТ, в которой они "тренируются" со своими изменениями (т.к. конфигуратор может открыть единовременно только один пользователь).
В итоге это уже три базы (боевая и две её копии), каждая размером под 100ГБ. Всего ~300ГБ. Сегодня они запросили ещё одну копию максимально сближенную по актуальности с боевой конфой УТ. Это ещё 100Гб.
Как-то настораживает.
А если у им потребуется редактировать ещё какую-нибудь другую конфу, выньте-дайте ещё 500Гб?
Или такой подход это единственный стабильный путь разработки?
 
 
   Timon1405
 
1 - 05.03.20 - 16:30
2020г, серьезно, экономия на дисках для программистов? крупная компания возьмет в аренду степлер?
   ДенисЧ
 
2 - 05.03.20 - 16:30
А что, написать скрипты, которые будут резать старые данные в базе - админ не позволяет?
Если им нужна максимально прилиженная - то это явно на момент итоговой проверки, то есть временно.
Вот за этим временно и надо следить...

ЗЫ. Тем более 100Г - это на так много.
   МимохожийОднако
 
3 - 05.03.20 - 16:32
(0) А меня настораживает настороженность.
   mikecool
 
4 - 05.03.20 - 16:32
накой вообще в торговле тянуть 100Г информации?
   ДенисЧ
 
5 - 05.03.20 - 16:33
(4) 100 розничных точек с миллионным оборотом каждая? )))
   Арбузов
 
6 - 05.03.20 - 16:34
(0) Это не проблема. А вот когда рабочая база размером 6ТБ...
   Keyn
 
7 - 05.03.20 - 16:34
100 Гб это ни о чем. Не хватает места, докупите диски, тем более это не дорого. У программистов должен быть оперативный простор для решения проблем. И несколько баз это вполне нормальная ситуация.
   fisher
 
8 - 05.03.20 - 16:35
(0) "Как-то настораживает"
Варианты есть, конечно. Но в наше время дешевле платить за место на дисках, чем ухудшением качества/скорости процесса.
   piter3
 
9 - 05.03.20 - 16:37
(0)Ну вы же на тестовое окружение наверняка какой-то шлак дали,то чего париться тогда
   Keyn
 
10 - 05.03.20 - 16:37
(6) А что в твоей базе 6 Тб? Сколько записей в самой большой таблице?
   letarch
 
11 - 05.03.20 - 16:38
Т.е. других вариантов нет. EDT и GIT не решат вопрос?
   Арбузов
 
12 - 05.03.20 - 16:40
(10) Данные, конечно. Сколько записей мне пофиг, пока не тормозит, а как будет тормозить - специально обученные люди этим займутся :)
   shuhard
 
13 - 05.03.20 - 16:41
(0)
1) базы крошечные и объёмы SSD/полки меньше 2 Тбайт не обсуждаются
2) базы на сиквеле сжимаются 1:3
3) в тестовых базах легко удаляются атташменты, версии объектов, ненужные для отладки в данный момент таблицы непосредственно на сиквеле
4) для отладки легко используются свёрнутые базы с набором данных за последний год
   shuhard
 
14 - 05.03.20 - 16:42
(11) ты путаешь кодирование(метаданные) и отладку (данные)
   letarch
 
15 - 05.03.20 - 16:44
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)
Т.е. других вариантов нет. EDT и GIT не решат вопрос?
   shuhard
 
16 - 05.03.20 - 16:46
(15) см. (14)
   Надо работать
 
17 - 05.03.20 - 16:48
(0) Можно сжать таблицы. Раза в 4 сожмет. Для дева нормально
   piter3
 
18 - 05.03.20 - 16:49
(15) Это про другое
   Кодер
 
19 - 05.03.20 - 16:52
EDT, GIT (и примкнувший к ним RegExp) решат вопрос, но добавят своих.

Не мешай разработчикам. Пока, по твоим словам, они всё делают правильно. Ключевым ресурсом рекомендую считать время, поэтому автоматизируй архивации, тестирования и всё, что они попросят. Это дешевле и лучше.
   Надо работать
 
20 - 05.03.20 - 16:54
(0) 3 базы ) у меня 160, из них 35 больше 100 гиг, из них две больше терабайта
   Надо работать
 
21 - 05.03.20 - 16:54
это только дев
   pechkin
 
22 - 05.03.20 - 16:56
либо находить место - либо как то кастрировать базу.
2 кстати совсем не тривиально.
есть еще вариант - покрытие тестами и база без данных.
но это самый сложный вариант
   pechkin
 
23 - 05.03.20 - 16:56
кстати для многотеррабайтных баз последний вариант практически единственно возможный
   Надо работать
 
24 - 05.03.20 - 16:57
по базе (каждой базе) и одна вчерашняя копия - это самый минимум для разработки
   dezss
 
25 - 05.03.20 - 17:04
(24) ОФФ: вот всегда твой ник хотелось поставить перед ником еще одного товарища с мисты))))
   shuhard
 
26 - 05.03.20 - 17:15
(23) синтетика наше всё
   palsergeich
 
27 - 05.03.20 - 17:16
(15) И как ЕДТ и ГИТ решат проблему отсутствия данных? Так то пустую базу можно из CF развернуть
   fisher
 
28 - 05.03.20 - 17:27
(15) EDT и GIT здесь непричем.
Речь про т.н. staging (или предпродакшн) - среду тестирования, максимально приближенную к боевым условиям (в идеале это должна быть полная реплика продакшна).
Просто во "взрослой" разработке он может быть один, а заливка доработок в него от всех разрабов и последующее тестирование осуществляются автоматически. Но там и команды большие (затраты на это лучше отбиваются) и инструментарий лучше и цикл разработки длиннее.
А ваши программисты просто пилят каждый в одно лицо и тестируют каждый в своем стэдже руками как могут. И это достаточно эффективно, если фичи не пересекаются, так как позволяет максимально сократить цикл разработки. И пытаться это изменить только лишь ради экономии дискового пространства - глупо.
   fisher
 
29 - 05.03.20 - 17:32
(22) Любая "кастрация" приводит к сокрытию проблем. Если у тебя недостаточно эффективный алгоритм, то он может успешно проходить все тесты в "кастрированном" окружении, а на "боевых" объемах и взаимосвязях оказаться неработоспособным.
   shuhard
 
30 - 05.03.20 - 17:34
(29) это базы dev, а не preprod
для них полный кортеж данных нн нужен
 
 Рекламное место пустует
   fisher
 
31 - 05.03.20 - 17:39
(30) Ты точно одинэсник? Отдельный предпрод у одинэсников бывает только в полумифических компаниях, которые на пальцах одной руки пересчитать можно. 90% пилят в копиях баз, которые суть гибрид предпрода и тестовой. И не полный предпрод они только по одной причине - одинэсники не любят заморачиваться с настройкой "горячих" реплик для этих целей. Просто когда база слишком уж устаревает для тестовых целей переходят на более свежую копию.
   DeeK
 
32 - 05.03.20 - 17:47
у нас канеш не по 100гиг но баз целый зоопарк и под хранилище каждому, и тестовых несколько чисто для пользователей, не жадничайте на дисках
   Fragster
 
33 - 05.03.20 - 17:49
Сожмите базы, если места жалко: http://catalog.mista.ru/public/114634/ + http://catalog.mista.ru/public/692209/ , будет раза в три-десять меньше весить
   vicof
 
34 - 05.03.20 - 17:52
Лучший способ разработки вдвоем - сидеть за одним компом и ловить друг друга на ошибках ;) и место экономится
   rphosts
 
35 - 05.03.20 - 18:45
(13) ну какое сжатие, базы-то средненькие.
   rphosts
 
36 - 05.03.20 - 18:46
(0) вышим кодерам совет - валить от работодателя, который более скряга чем Плюшкин!
   rphosts
 
37 - 05.03.20 - 18:47
(20) проглот!
   shuhard
 
38 - 05.03.20 - 18:56
(31) сейчас точно одинэсник
препрод готовим для каждого, поскольку mdf ERP ближе к 300 Гбайт, а баз десятки, тем более в момент подготовки релиза
   Prog111
 
39 - 05.03.20 - 18:59
Вы что несёте? Да они на операциях сжатия-разжатия потратят больше времени (читай: денег)... Если не ошибаюсь, диск в 1-2 ТБ стоит в пределах 10 тыс. руб., если они не будут тратить время на оптимизацию - то за неделю этот диск окупят.
   letarch
 
40 - 06.03.20 - 08:38
(19) (20) (24) (28) спасибо всем за пояснение, будем пробовать :-)
   Fragster
 
41 - 06.03.20 - 12:01
(39) диск медленнее процессора, бэкап скуля со сжатием делается быстрее, чем без сжатия, например. и восстановление такого бэкапа тоже быстрее.
   ДенисЧ
 
42 - 06.03.20 - 12:14
(39) А ты пробуй сво1 468sx заменить хотя бы на селерон дуо два...


Список тем форума
Рекламное место пустует  Рекламное место пустует
Основная теорема систематики: Новые системы плодят новые проблемы.
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.