Модель обслуживания внешних артефактов

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

  

«Сделайте следующее (ручное) изменение конфигурации для фермы как часть развертывания этой версии xx.yy.zz пакета решений.»

Я реализовал довольно хорошую модель для этого, но теперь я решаю следующую самую большую проблему - как мы управляем изменениями в других системах, которые у нас нет? Рассмотрим простой пример:

У нас есть приложение ASP.NET, принадлежащее команде разработчиков (назовем их командой PLM). Их следующий выпуск включает изменение, которое требует, чтобы команда SAP (которая находится под другим зонтом обслуживания) также развертывала изменение одной из своих конечных точек BAPI.

Конечно, фактическая координация развертывания во время выпуска представляет собой простое взаимодействие человека и amp; координации, но с точки зрения общей SDLC:

  • Как наш пример пакета PLM Team & отслеживать эту зависимость как артефакт, как в качестве предстоящего изменения, так и после развертывания, управляемую зависимость с требованиями, которыми они владеют, но не контролируемую им реализацию?
  • Какая информация нужна для захвата? Как его следует обрабатывать иначе, чем элементы конфигурации без кода, которые они контролируют?
7 голосов | спросил Rex M 24 PM000000110000003731 2012, 23:17:37

1 ответ


1
  • Если две команды постоянно общаются, это скорее взаимодействие людей и координация, а не деловые процессы. Вы просто согласны с тем, как изменится интерфейс, используемый обоими проектами, вы измените его и одновременно разворачиваете оба продукта. К тому же, я имею в виду, что вы отключите машину от фермы, вы остановите оба приложения, затем обновления применяются к обоим приложениям, а затем они снова запускаются, и машина может вернуться в ферму.

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

В этом втором случае вы выступаете в роли крупного поставщика API, который выпустил новую версию API, но имеет множество клиентов, которые все еще используют старую версию. Если следующая версия не расширяет¹ первый, но меняет2, вы должны продолжать обе версии.

Это означает, что у вас будут оба:

http://api.example.com/products/get/5

и

http://api.example.com/v2/d6w9UbnZ50/products/get/5
                       ↑       ↑
                    version  token

, и в то время как новые клиенты смогут использовать API RESTfull, используя вторую версию, более старые клиенты, которые полагаются на сеансы, по-прежнему смогут использовать API.

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


¹ Расширение: добавление необязательного аргумента в существующий метод или добавление перегрузки или новый метод не нарушает текущий API.

² Изменение: переименование методов, чтобы сделать их более явными или удалить аргумент или добавить обязательный, приведет к поломке текущего API.

ответил Arseni Mourzenko 25 PM00000030000001931 2012, 15:23:19

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132