Жизненный цикл разработки API

Вы просматриваете документацию по Apigee Edge.
Перейдите к документации по Apigee X. Информация

У каждой организации свой жизненный цикл разработки ПО (SDLC). Часто необходимо синхронизировать и согласовывать развертывание прокси-сервера API с процессами, которые вы используете для разработки, тестирования и развертывания других приложений.

Сервисы API предоставляют инструменты и RESTful API, которые позволяют интегрировать развертывание и управление прокси-серверами API в SDLC вашей организации. RESTful API часто используется для написания скриптов или кода, которые программно развертывают прокси API или переносят их из одной среды в другую в рамках более крупного автоматизированного процесса, который также развертывает или переносит другие приложения. API Services не делает никаких предположений о вашем SDLC (или чьем-либо ещё). Он предоставляет атомарные функции, которые ваша команда разработчиков может использовать для автоматизации и оптимизации жизненного цикла разработки API.

Документация по API сервисов API приведена в справочнике по API. Подробнее о начале работы с документацией по API…

Посмотрите видео о средах API и жизненном цикле разработки API.

Среды

В каждой организации Apigee Edge есть как минимум две среды развертывания, доступные для прокси API: test и prod. Разница между этими средами условна: каждая из них определяется набором сетевых адресов (URL). Цель – предоставить вам домен, в котором вы можете создавать и проверять прокси API до того, как API станет доступен внешним разработчикам.

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

Для каждого окружения автоматически включается входящий TLS/SSL на сервере. В каждой среде предварительно определены два виртуальных хоста: default и secure. По умолчанию определяется адрес HTTP, а при выборе защищенного подключения – адрес HTTP/S с предварительно настроенным на стороне сервера протоколом TLS/SSL. В конфигурации прокси-сервера API вы указываете, какие виртуальные хосты должен прослушивать ProxyEndpoint. При переносе в рабочую среду обычно отключается HTTP путем удаления defaultVirtualHost из конфигурации прокси-сервера API.

Например, следующий ProxyEndpoint прослушивает HTTP и HTTPS.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Удалив default VirtualHost из конфигурации ProxyEndpoint, вы создадите прокси-сервер API, который будет прослушивать только HTTPS, а не HTTP.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Чтобы посмотреть, какие виртуальные хосты доступны в среде, выберите Среды в главном меню интерфейса управления.

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

Как развернуть прокси API в средах

При создании прокси-сервера API вам нужно будет выбрать среду, в которой вы будете работать. Вы можете создать новый прокси-сервер API в рабочей среде, но это не рекомендуется, так как вы можете предоставить разработчикам доступ к API до того, как он будет готов. Как правило, сначала создается прокси-сервер API в test, который после тестирования переносится в prod.

Подробнее о развертывании…

Итеративная разработка в тестовой среде

Когда вы работаете с прокси-сервером API, API Services сохраняет итерации вашей конфигурации в виде версий. При развертывании прокси-сервера API вы выбираете определенную версию. Обычно вы развертываете последнюю версию, а при необходимости возвращаетесь к предыдущей. Вы можете выбрать, где развернуть эти версии. Например, вы можете перенести в рабочую среду новую версию, чтобы разработчики могли начать работать с вашим API. В то же время вы можете тестировать несколько версий, добавляя функции или настраивая правила. Затем, когда вы будете готовы, вы можете развернуть новую версию в рабочей среде, перезаписав существующую версию в этой среде. Этот метод позволяет всегда иметь доступную для разработчиков рабочую версию API, пока вы его разрабатываете.

Перенос в рабочую версию

Когда прокси-сервер API будет полностью реализован и протестирован, его можно будет перевести в рабочую среду. Версия прокси-сервера API в тестовой среде будет использована для перезаписи версии прокси-сервера API, развернутой в рабочей среде.

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

Развертывание скриптов

В интерфейсе управления Apigee Edge можно развертывать прокси API в рабочей среде непосредственно из конструктора прокси API. Однако во многих ситуациях требования к безопасности, надежности и согласованности будут обязывать команды разработчиков создавать скрипты для процедур развертывания. Для этого можно написать код и скрипты, которые вызывают RESTful API, предоставляемый сервисами API.

Ресурсы для окружающей среды

Чтобы обеспечить дополнительный контроль во время промоакции, рекомендуем вносить изменения в прокси API только в тестовой среде и как можно реже – в прокси API, развернутые в рабочей среде.

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

  • Целевые URL. Прокси API часто вызывают разные URL серверной части во время тестирования и в рабочей среде. Вы можете использовать конфигурации TargetServer, чтобы создавать конфигурации TargetEndpoint, не зависящие от среды. Подробнее…
  • Кэш и карты "ключ-значение". Оба ресурса постоянного хранения данных ограничены средой. Убедитесь, что используются правила именования, позволяющие прокси-серверам API хранить данные без необходимости менять конфигурацию при переносе. Подробнее о том, как создавать и изменять кеш среды…
  • Цели ServiceCallout. Для выносок с предложением услуг могут использоваться разные цели в зависимости от среды, например если выноска с предложением услуг в тестовой среде использует демонстрационный сервис. Ознакомьтесь с правилами в отношении описаний услуг.

Чтобы конфигурации прокси-сервера API не зависели от среды, можно также использовать условные операторы. Условное выражение, созданное с помощью переменной environment.name, можно использовать для оценки текущей среды перед применением правила или переадресацией на URL на сервере.

Подробнее о развертывании…