Понятно, что клиент исходники не отдаст. Но почему не сделать профиляцию на клиентской машине в момент возникновения проблемы? Дамп процесса ведь вам отдали, а снэпшоты dotTrace/dotMemory содержат уж точно не больше sensitive данных.
А насчет генерации тестового проекта, интересно, это ваш собственный внутренний алгоритм? Или что-то за основу взято? (у меня возникала схожая задача, но решил не связываться, показалось слишком трудоемким)
А меня вот заинтересовало, как Вы «создали свой тестовый проект с большим количеством сложных конструкций»? Задача вроде-как нетривиальная. Вряд ли для тестов анализатора представляет интерес искуственно нагенерированные for/if/etc конструкции. Полагаю, Вы просто выбрали проект из вашей обширной библиотеки, который имел близкие статистические показатели?
И еще вопрос, а почему было не снять performance/memory снэпшоты прямо с проблемной клиентской машины? У dotTrace/dotMemory есть консольные версии, которые не требуют установки и лицензии — в целом не сильно сложнее, чем взять дамп процесса.
Да, собственно с миграцией данных и был связан вопрос. Понятно, что изменение схемы обработается нормально.
Я подумал, вдруг у RedGate есть возможность а-ля рефакторинг в стиле ReSharper, например говорим «переместить поле в справочник» и автоматически генерируется скрипт не только для схемы, но и для данных… но видимо, нет.
Скажите, возникает ли у вас следующая ситуация. Допустим есть таблица T1 с полем f1. Затем мы понимаем, что нам нужен справочник T2 и поле f1 должно быть в нем, а T1 должна ссылаться на T2. Способен ли RedGate обработать такую ситуацию?
А как у Вас обстоят дела с тестовыми данными — dev-база содержит реальные данные из production (как и когда синхронизируется)? или там полностью синтетические данные (кто и как их генерирует)?
Во-первых, вообще-то не ограничился «прогоном юнит тестов», у нас довольно много шагов выходящих за рамки юнит тестов. Я упоминаю об этом в описании «идеального» процесса.
Во-вторых, Вы справедливо разделили Continuous Integration и Continuous Delivery. И из того, что PowerShell хорошо подходит для delivery, не следует, что и все другие задачи тоже следует решать с его помощью. В наших задачах PowerShell сильно проигрывал F#.
Кстати, оба подхода вполне могут «жить дружно» — не вижу ничего плохого, в том, что delivery будет описываться отдельным ps-скриптом и выполняться в рамках своего build definition-а в TFS-е. И даже, если очень хочется, чтобы это был один скрипт, то можно поднять PowerShell host внутри AnFake-а и вызвать стандартные PowerShell модули от Microsoft.
Вполне возможно, Вы правы насчет потери актуальности. Но у меня были задачи, которые надо было решить здесь и сейчас. В процессе решения появился инструмент, о коем я и рассказал — может кому-то будет полезен.
А насчет генерации тестового проекта, интересно, это ваш собственный внутренний алгоритм? Или что-то за основу взято? (у меня возникала схожая задача, но решил не связываться, показалось слишком трудоемким)
И еще вопрос, а почему было не снять performance/memory снэпшоты прямо с проблемной клиентской машины? У dotTrace/dotMemory есть консольные версии, которые не требуют установки и лицензии — в целом не сильно сложнее, чем взять дамп процесса.
Я подумал, вдруг у RedGate есть возможность а-ля рефакторинг в стиле ReSharper, например говорим «переместить поле в справочник» и автоматически генерируется скрипт не только для схемы, но и для данных… но видимо, нет.
Спасибо за ответ.
Во-вторых, Вы справедливо разделили Continuous Integration и Continuous Delivery. И из того, что PowerShell хорошо подходит для delivery, не следует, что и все другие задачи тоже следует решать с его помощью. В наших задачах PowerShell сильно проигрывал F#.
Кстати, оба подхода вполне могут «жить дружно» — не вижу ничего плохого, в том, что delivery будет описываться отдельным ps-скриптом и выполняться в рамках своего build definition-а в TFS-е. И даже, если очень хочется, чтобы это был один скрипт, то можно поднять PowerShell host внутри AnFake-а и вызвать стандартные PowerShell модули от Microsoft.