Как вы работаете с версиями в многостороннем проекте?

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

У нас есть многосторонний проект со следующими основными компонентами:

• Сервер, на котором размещена основная бизнес-логика (модели данных)
• Бэк-офис для клиентов, который использует основную бизнес-логику
• API приложения (REST), который также использует основную бизнес-логику
• Существуют приложения для смартфонов (iOS и Android), использующие API приложения
• Есть другое приложение для планшета (android), отличающееся от приложения для смартфона, использующее тот же API-интерфейс приложения.

Скоро я буду в производстве с активными клиентами. И, как и любой проект, мне нужно будет поддерживать все различные компоненты с течением времени. Это означает, что все следующее может быть обновлено:

• код основной бизнес-логики на сервере (используется бэк-офисом, API и, как побочный эффект, мобильными приложениями)
• сам API (используется приложениями для смартфонов и планшетов)
• все мобильные приложения (через appstore / googleplay)

Конечно, части сервера (основной код бизнес-логики и код API) могут быть изменены непосредственно мной. Однако новые мобильные приложения должны быть загружены клиентами в appstore / googleplay, и я не уверен, что они обновлены.

Не могли бы вы дать какие-либо рекомендации, советы по передовому опыту, чтобы обновления были гладкими и без риска для клиента?

Какой компонент мне нужен для «версии»? Как убедиться, что все работает, даже если клиент не обновляет свое мобильное приложение? Должен ли я заставить его обновиться, чтобы облегчить мою работу?

Одним словом, как мне организовать свой многогранный проект с течением времени?

Поскольку вы не можете контролировать, когда мобильные приложения будут обновлены до новой версии, вам необходимо обновить хотя бы ваш REST API. Если вы этого не сделаете, будет невозможно внести обратно несовместимые изменения в этот интерфейс.

Помимо REST API, хорошей идеей является создание версий и других коммуникационных интерфейсов, которые проходят через сетевой интерфейс. Таким образом, вы также не обязаны обновлять все клиенты backoffice одновременно с серверами, и вы можете осуществить постепенный переход на новую версию с периодом «бета-тестирования».

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

Этот пост представляет интересный вопрос о вашем вопросе.

Более практично, если у вас есть 3 компонента:

• 2 Потребителя: интерфейс и мобильное приложение
• 1 провайдер API: бэкэнд

Вы могли бы использовать типичную схему управления версиями Mmp (Major.minor.patch) для каждого, но в своем внутреннем URL вы могли бы поместить что-то как http://youhost/M.m/resourceURI.

По мере вашего развития и изменения в API не влияют на ваш контракт с потребителями, вы сохраняете M.mкак есть в URL. С того момента, как вы вносите изменения в BackEnd, которые влияют на ваших потребителей (будь то изменение в поведении или другой объект), вы используете M.m+1, M+1.m+1или M+1.m.

Чтобы сохранить работоспособность, нужно развернуть новый Back-End одновременно со старым, в то время как ваши пользователи установят новых потребителей и постепенно прекратят работу старого API.

Вы можете найти лучший ответ, чем мой, здесь: Управление версиями REST API в Stackoverflow

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

1. Каждый компонент будет иметь версии, когда он будет выпущен. Это включает в себя библиотеки низкого уровня, а также ваши конечные продукты.
2. Каждая фиксация кода запускает создание снимка. Это помогает сохранять честность ваших разработчиков, особенно если вы используете средство для отправки электронной почты виновнику, который нарушил сборку.
3. Каждая сборка может запускать юнит-тесты. Это заметно улучшает качество кода.
4. Каждый выпуск будет помечен тегом, поэтому, если требуется исправление, легко перейти от тега и выполнить исправление.
5. Вам нужно будет поддерживать какой-либо регистр совместимости. (например, BackOffice 1.0.23 совместим с REST API 2.0.267 и т. д.). Я не знаю инструмента, который поможет в этой области.

Мой опыт работы с инструментами с открытым исходным кодом: SVN, Maven 2, Jenkins и Nexus, но есть альтернативы всем этим.

Не стоит недооценивать время обучения, чтобы ваша команда набрала скорость. Но как только они наберут скорость, они никогда не вернутся.

Для относительно небольшой команды по разработке и развертыванию модель совместимости Client N-1, используемая IBM Jazz, может работать довольно хорошо

Старайтесь, чтобы клиенты и серверы имели одинаковый номер версии. [Вместо управления матрицей независимых версий и их совместимости]

Разработайте политику, согласно которой клиентская версия Xyy должна работать со всеми версиями серверов выше Xyy, но ниже X + 2.0.0.

Для версии сервера 4.0 в идеале должна быть версия клиента 4.0 для каждого типа клиента. Тем не менее, совместимость должна поддерживаться таким образом, чтобы допускались несколько разные версии клиентов и серверов.

Клиентская версия 4.x должна быть совместима с серверами версии 4.x и выше, но ниже 6.0; Сервер 4.x должен быть совместим со всеми клиентами версии 3.0 и выше, но меньше или равен 4.x

Таким образом, вы можете обновить версию на сервере, не беспокоясь о немедленном выпуске новых версий клиентов, но у вас будет только четко определенное окно совместимости для поддержки.

Ссылка: IBM Jazz Model [ https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html].

Во-первых, я начну с того, что сформулирую проблему немного иначе. Вы спросили, какие части программного обеспечения вам нужно для «версии». Версия является перегруженным термином в CS и может означать около 100 разных вещей. Основные вещи, на которые я бы посмотрел:

1. Контроль версий. Контроль версий - это инструмент управления конфигурацией, который помогает вам отслеживать моментальные снимки и историю разработки. ВСЕ КОДЫ ДОЛЖНЫ БЫТЬ ПОД КОНТРОЛЕМ ВЕРСИИ. Мне все равно, если это просто удобные сценарии, которые вы добавляете в папку bin, все, что стоило потратить время на написание, стоит двух секунд, чтобы добавить его в программу контроля версий.
2. Управление конфигурацией - Как я могу контролировать то, что находится в сборке. Все программное обеспечение должно иметь некоторую степень управления конфигурацией. Я хотел бы рассказать менеджерам о разнице между контролем версий и управлением конфигурацией, поскольку контроль версий - это всего лишь инструмент для отслеживания истории разработки, в то время как управление конфигурацией - это руководство для того, как мы создаем историю, и как мы делаем такие вещи, как определение кода. хороший.
3. Управление версиями программного обеспечения - присвоение имен выпускам кода. Это то, что многие люди фиксируют, когда впервые видят проблему, потому что они привыкли видеть «MineSweeper 7.1.29290149210» или что-то еще на предметах, которые они покупают, но, честно говоря, я считаю, что это самая незначительная часть гораздо большей проблемы. Честно говоря, просто использовать хеш, сгенерированный 1, и не заботиться о том, чтобы его не читалось человеком, - это прекрасно.

Так как это самый туманный и самый интересный для меня, я просто собираюсь сосредоточиться на # 2. Не существует единого универсального решения для управления конфигурацией файлов cookie. Правила, которые хорошо работают для команды из 2 или 3 человек, могут быть слишком свободными, чтобы сохранить здравомыслие в проекте, который требует сотни рабочих. Правила, которые работают в большой команде, могут потребовать слишком больших накладных расходов для небольшой команды. Скорее всего, вам придется что-то сделать самостоятельно, чтобы собрать что-то вместе, но я бы использовал следующий список для разработки спецификаций вашей системы управления конфигурацией:

1. Как я могу отслеживать версии (и связанные с ними проблемы), которые я поддерживаю на рынке?
2. Как я решу, какие пути разработки готовы для выпуска в производственные системы? (Он также может быть готов к любому другому шагу в процессе)
3. Кто должен контролировать / управлять конфигурацией системы? Каков рабочий процесс для добавления кода для распространения другим разработчикам?
4. Как я собираюсь контролировать взаимодействие между взаимодействующими частями? Как я узнаю, что замена части сломает остальную часть системы?
5. Как мы будем совершенствовать нашу систему управления конфигурациями с течением времени.

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