Использование объектов предпочтений для хранения внешней информации для ралли

Question

Предпочтения объектов представляют способ хранения произвольных данных в ралли, которые могут быть объединены с другой информацией о ралли.

Например, если я хочу рассчитать плотность дефектов и увидеть график в ралли, я не могу, потому что у меня нет информации KLOC в Rally. Но если я пишу скрипт, который периодически меняет текущее количество строк на каждую итерацию или около того в объект предпочтения хорошо знакомого идентификатора, я могу сделать это легко.

Должен ли я? И если да, то каковы ограничения объектов предпочтений в Rally? Сколько данных я могу безопасно хранить в них, и сколько объектов настроек может разумно справиться с системой? Это сотни, тысячи, десятки тысяч? Наш экземпляр уже имеет тысячи из них только из стандартных приложений, которые установлены, поэтому похоже, что ответ составляет не менее тысячи.

Answer 1

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

С другой стороны, я хотел бы узнать больше об анализе, который вы имеете в виду. Перед приездом на ралли я немного поработал using LOC to normalize metrics, а также до heuristically determine artifact dependency. Теперь на Rally у меня есть как функции аналитики, так и функции соединителя в моей области ответственности в качестве владельца продукта, и я изучал способы ответственно использовать LOC на Rally.