Team Development

Team Development
You can use
CA Live API Creator
in the context of multiple (concurrent) API developers or as a single, disconnected API developer. If you are using 
CA Live API Creator
 as a single, disconnected API developer, you can use the single-user demonstration package of
CA Live API Creator
 that is based on Jetty (the demonstration package). You can support team development by using a blend of the demonstration package and other Java container deployed environments. The demonstration package installation includes an admin repository to support your development locally.
For more information about the admin repository, see View your API Definition.
In this article:
API Lifecycle Management 
You can script the following API lifecycle management tasks:
  • Lifecycle operation.
     For example, you can script the movement of a system from development, to test, and then to production.
  • The API-to-API server deployment from source control system (SCS) artifacts.
     For example, you can save development artifacts and export admin contents into a file for maintenance into an SCS (such as the export artifact).
  • The creation of APIs into an API server in a production system.
With team development, the team of API developers can:
  • Work in parallel and develop code independently in their own environment, avoiding potential concurrency issues or overwriting code developed by other API developers. As the API developer changes their API, API Server writes these changes to the admin repository that is located in the API developer's file directory. The synchronization process in 
    CA Live API Creator
     attempts to match the file system with the data model that is stored within the in-memory Derby database for the API developer's API metadata.
    For more information about the admin repository, see View your API Definition.
  • Perform code review activities, such as comparing (files) to determine how or whether the files differ (code diff) and code merges, offline. 
  • Check in their final code to an SCS after completing the code review. 
    CA Live API Creator
     is not bound to a specific SCS.
  • Automate the deployment of API changes to other environments using existing Continuous Integration/Continuous Deployment (CI/CD) and DevOps processes.
Team Development Workflow
Most projects engage a team of API developers. The following illustration depicts a typical team development workflow using
CA Live API Creator
API developers design their APIs locally on their 
CA Live API Creator
 instance using the following process:
  1. Typically, each API developer works in their local instance of
    CA Live API Creator
    , accessing either a local or shared application development database. API developers can use the demonstration package or run 
    CA Live API Creator
     on Apache Tomcat or in another Java container.
  2. Each API developer sets up their local instance of 
    CA Live API Creator
     by completing the following steps:
    1. Stops API Server.
    2. Checks out or clones their API from your Source Control System (SCS) to the admin repository. For example, the API developer can copy an existing Git repository by issuing the 
      git clone
      The API name and the URL fragment of the API that you are pulling into your local instance must not conflict with any existing APIs.
    3. Changes their API.
  3. When the API developer is ready to check in code or update their environment with the latest changes from the SCS, the API developer does the following:
    1. Stops API Server.
    2. Performs code diffs, merges, and updates within the directory for their API (the 
       directory that is in the admin repository). For example, the API developer can use Git.
    3. Updates the 
       directory with the latest changes from the SCS.
    4. Restarts API Server.
      Reload the schema to see new database objects. For more information about how to reload schemas, see Database Administration.
API developers repeat these steps iteratively throughout the development process.
DevOps Workflow
The following illustration depicts a typical DevOps workflow using 
CA Live API Creator
DevOps deploys APIs after an API developer has verified that their code has merged or updated successfully. The API developer repeats steps 1 and 2 as needed.
Use the following process:
  1. When the API developer is ready to check in code into the SCS for deployment, the API developer exports the API (the ZIP or JSON file), and then checks in this exported file into their SCS.
  2. Using existing CI/CD and DevOps processes, the API developer completes the following steps:
    1. If their API authenticates API users using a custom authentication provider and you are moving your API from one TeamSpace to another, scripts the import of their previously exported authentication provider from their local development environment from their SCS into the TeamSpace.
      For more information about how to script the import of authentication providers into TeamSpaces, see Import and Export Authentication Providers.
    2. Imports the exported API (the JSON or ZIP file) into their test environment.
      For more information about how to import an API using scripts, see Import and Export APIs.
    3. Fixes the imported API.
      For more information about how to fix imported APIs, see Import and Export APIs.
    4. Runs their automated test suites using their testing framework.
  3. The API developer deploys the API to the production environment by using
    of the following options:
    • Importing the API (the ZIP or JSON file).
    • Checking in the API (the ZIP file), then passing in the repository URL location by way of adding the 
       option when you start API Server.
Team Development Best Practices
We recommend the following best practices when working as a development team using
CA Live API Creator
  • If your API is using data sources, you can export your API with data source passwords as encrypted or plaintext using the API export options. While the practice of exporting data source passwords in plaintext is not recommended as you deploy to test and production environments, this practice can be useful during the initial stage of development. You can share and restart an API development or sample project that requires database schema and meta information.
  • After importing an API with the latest changes in your development environment, consider reloading the schema especially when the schema is still evolving.
For a list of all best practices, see Best Practices.