Как использовать Sign off и sign off with issues на Environment history?

[Yrich]

Здравствуйте!
Помогите пожалуйста разобраться и понять.

D365 FO (10.0.14)
Update38 (7.0.5778.41503)

LCS. В документации при обновлении Tier 2 или Prod (9 пункт) можно делать Sign off и Sign off with issues на Environment history.

1.Но зачем?
2.С какой целью? В каких ситуациях она используется?
3.А если не сделать то что?
4.В чем разница между Sign off и Sign off with issues?

Прочитав дополнительную информацию здесь и здесь не совсем понятно.

[sukhanchik]

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

[skuull]

Если его не sign off то оно не появиться в списке на деплоймент в прод, вот и все.

[Yrich]

Цитата:

Сообщение от skuull

Если его не sign off то оно не появиться в списке на деплоймент в прод, вот и все.

Цитата:

Сообщение от sukhanchik

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

Не совсем. Для всего выше перечисленного есть кнопка Mark as release candidate в Environment history. При нажатии которой чекбокс Is release Candidate измениться на YES. И ТОЛЬКО этот пакет будет показан в списке обновлений для PROD.



Я даже для одного с пакетов на UAT нажал Sign off. Но ничего не произошло. В пакетах для деплоймента PROD он не появился, смотрите скриншот выше.

[skuull]

А это баг, раньше, до бага, sign off делал то что вы делаете руками и в истории оставлял запись о sign off. Сейчас только запись,что тоже неплохо для аудита.

[Vadik]

Давным-давно, когда Земля еще была раскаленным шаром, Sign off использовался как ручное подтверждение завершенного deployment-а (без него нельзя было начать деплоить новый пакет). Сейчас, в свете движения в сторону DevOps и CI, смысл такого его использования плавно снижается до нуля. Пока что я так понимаю кпопку не выпиливают так как она предлагает пометить пакет как RC. Sign off with issues использовал один раз пару лет назад (не помню зачем ), он перевел упавший пакет и само окружение в какую-то раскоряченную комбинацию servicing и deployment state из которого их несколько дней выводили с саппортом и DSE. С тех пор не пользовался

[vmoskalenko]

Цитата:

Сообщение от Vadik

Давным-давно, когда Земля еще была раскаленным шаром, Sign off использовался как ручное подтверждение завершенного deployment-а

И было еще одно применения, которое точно также ушло. А именно для версионности. Вы наверное видели что в LCS Asset Library можно иметь несколько версий для одного и того же пакета. Так вот, для того чтобы загрузить новую версию пакета надо было сделать Sign Off пакета.

Версионнасть работала вот так:

1. Загружали пакет в Shared Asset Library
2. Нажимали кнопку Publish прямо там (Scope менялся в Organization)
3. Пакет Just me удалялся
4. Заходили в Project Asset Library
5. Импортировали пакет (кнопка Import)

Если надо было добавить новую версию, то делали примерно тоже самое

1. Проверяли что предыдущие пакеты на ВСЕХ серверах помечены как Signed Off
2. Находили существующий пакет в Shared Asset Library
3. Загружали пакет в Shared Asset Library
4. Заходили в Project Asset Library
5. Импортировали пакет (кнопка Import)
6. Версия увеличивалась - надо запомнить эту версию при установке на сервер.

Плюсы:
Asset Library был компактней

Минусы:
Надо было проверфть N+ серверов на наличие Signed Off пакета
CD от Майкрософта не поддерживает эту версионность

Цитата:

Сообщение от Vadik

... С тех пор не пользовался