CA API Gateway 9.1

9.4 9.1

Implementing a Policy Development Life Cycle

A traditional Software Development Life Cycle (SDLC) focuses on configuration management, essential for tracking and predicting which artifacts are included in a production build. A Policy Development Life Cycle (PDLC) employs similar concepts and tooling. You need to keep tracking of versions and perform rollbacks if necessary. There are phases for development, testing, and deployment. However the PDLC is further complicated by differences in environments; for example, you cannot reliably test a Gateway policy for a user acceptance environment by connecting to a development LDAP server. You need to connect to an LDAP server that is configured for production.
gateway91
A traditional Software Development Life Cycle (SDLC) focuses on configuration management, essential for tracking and predicting which artifacts are included in a production build. A Policy Development Life Cycle (PDLC) employs similar concepts and tooling. You need to keep tracking of versions and perform rollbacks if necessary. There are phases for development, testing, and deployment. However the PDLC is further complicated by differences in environments; for example, you cannot reliably test a Gateway policy for a user acceptance environment by connecting to a development LDAP server. You need to connect to an LDAP server that is configured for production.
Developers working in the SDLC will find much familiarity in the PDLC. Just treat your configuration artifacts (policies and their dependencies) as source code, specifically XML. The PDLC has a specific phase that deals with resolving environmental dependencies.
Terminology
  • Service
     refers to the API the Gateway presents to the users. This could be standard SOAP services, REST services, JSON, or various kinds of networked XML and non-XML APIs.
  • Environmental Dependencies
     are the specific components that a service depends upon, for example: Public Keys, Private Keys, LDAP configurations, JMS configurations, JDBC configurations, MQ Series configurations, etc. The dependency will be referenced by name when discussing details.
  • DEV
     refers to the initial policy development environment.
  • QA
     refers to the initial quality assurance environment.
  • UAT
     refers to the acceptance testing and/or performance testing environment.
  • PROD
     refers to the deployed environment in front of production services and APIs.
Policies are Code and Deserve Similar Attention
In enterprise deployments that include infrastructure components such as the
CA API Gateway
, it is critical to manage configuration artifacts in a repeatable and reliable way. Most organizations are familiar with deploying software to application servers. This section shows you how to leverage this knowledge to deploy policies to infrastructure.
CA Technologies provides tools and interfaces for an organization to plan a life cycle around for their environment.  As every organization has its own way of deploying production environments, some parts of this process will already be in place. What is important is the effect of these processes, not the exact steps.
Best Practices
CA Technologies has compiled the following valuable tips, based on many deployments:
  • Develop a policy and its environmental dependencies in a test (i.e., non-production) environment.
  • Copy the complete version of these artifacts to a test environment with no shared infrastructure
  • Make the local changes needed to be compatible with the test environment.
  • Local changes should be environment specific (for example, IP addresses, host names of Application Servers or LDAP servers).
  • Test the system to be sure your components are working.
  • Copy the same components to the next step in the deployment pipeline.
  • The original developer should not be responsible for moving artifacts to production, nor be responsible for testing.
  • Part of good development practice is to have repeatable creation of your systems.
  • If documentation isn't sufficient to do full deployment, fix the documentation. Do not assign the original developer.
  • Certain kinds of environment specific artifacts, like host names of back end servers, should use cluster properties instead of literals.
  • Naming conventions for objects can ease resolution of environment dependencies.
  • For predictability, configuration must be pushed as a unit, and the tested versions of each artifact be used.  Version control features like tags and/or branches can help.
  • Local dependencies are worked out by moving from development to testing or user acceptance.
  • Moving directly from DEV to PROD is risky, as testing the dependency discovery is critical.
  • Never make changes in PROD. Always do changes in DEV and move to QA, etc.
  • Do not share environment items like LDAP between DEV and UAT.
  • Sharing environments without a clear goal in mind will almost certainly cause a failure moving to production.
GUI-Based Policy Migration Using the Policy Manager
The Policy Manager provides a simple way of migrating policies between environments via its import and export capabilities. However, these methods do not preserve mapping between multiple environments, making them less suitable for larger deployments and multiple policy development groups.
Automated Policy Migration Using Management APIs, GMU, CMT
For environments that do not allow GUI tooling for managing production systems, the Gateway provides several command line options:
For more information, see Develop Migration-Friendly Policies.
CMT/GMU
Gateway versions 8.3 and later include the Gateway Migration Utility (GMU) to cover policy migration use cases. Earlier versions of the Gateway are supported by Command line Policy Migration Toolkit (CMT), which is also available in the later versions.
For GMU and CMT, version control is critical. As locally preferred tooling (Subversion, ClearCase, Polytron Version Control, Git, etc.) is widely varied, CA Technologies cannot prescribe a specific tool, but rather expects three main capabilities of a version control system:
  • Can check in and check out based on a "tag" or "release name" that encompasses many files and many directories
  • Can deal with XML as text
  • Can be run using command line tooling
Internally, the Gateway uses Object Identifiers (OIDs) and Global Object Identifiers (GOIDs) to identify various configuration items.  When dealing with multiple environments and multiple staff members being involved in the process, name-based identifiers are beneficial. The GMU tooling deals with resolving names to local objects.
Similarly, develop naming conventions to identify the back-end App Servers and any artifacts.
Conclusion
Creating a Policy Development Life Cycle that mirrors the software development life cycle at your organization is the first step to a reliable process. The Gateway provides the tools and capabilities that can adapt to any environment. Planning is essential. Once the process is in place, it can and should be fully automated.
The Gateway's policy language supports diverse use cases. Plan for environment dependencies, choose good modularity, and above all think in policy in the same way as source code.

Content feedback and comments