Team Development

Team Development
lac52
You can use 
Layer7 Live API Creator
 in the context of multiple (concurrent) API developers or as a single, disconnected API developer. If you are using 
Layer7 Live API Creator
 as a single, disconnected API developer, you can use the single-user demonstration package of 
Layer7 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 
    Layer7 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. 
    Layer7 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 
Layer7 Live API Creator
:
TeamDev5_0.png
API developers design their APIs locally on their 
Layer7 Live API Creator
 instance using the following process:
  1. Typically, each API developer works in their local instance of 
    Layer7 Live API Creator
    , accessing either a local or shared application development database. API developers can use the demonstration package or run 
    Layer7 Live API Creator
     on Apache Tomcat or in another Java container.
  2. Each API developer sets up their local instance of 
    Layer7 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
       command.
      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 
      teamspaces/apis/<urlname>
       directory that is in the admin repository). For example, the API developer can use Git.
    3. Updates the 
      teamspaces/apis/<urlname>
       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 for Deploying API Server-Level Configurations
DevOps engineers can deploy API Server-level configurations after the API developer has verified that the configurations have merged or updated successfully. 
API Server-level configuration files can include any of the following that are part of your admin repository:
  • The data source providers that you define. API Server saves the configuration files for each data source provider in a file that is located under the 
    system/data_source_providers
     directory.
    For more information about how to define a data source provider, see Manage Data Source Providers.
  • The configurations that you define to activate 
    Layer7 Live API Creator
     and configure it to send usage data. API Server saves these configurations in the 
    system/telemetry.json
     file.
    Updating this file is part of the DevOps workflow, whether running 
    Layer7 Live API Creator
     under a Portfolio License Agreement (PLA) or under a standard license.
    For more information about how to configure this file, see Activate and Configure to Send Usage Data.
Use the following process:
  1. The DevOps engineer checks the configuration files that are located in the admin repository into their SCS.
  2. Using existing CI/CD and DevOps processes, the DevOps engineer completes the following steps in the next deployment environment:
    1. Stop API server.
    2. Deploys the configuration files.
    3. Stop and restart API server.
DevOps Workflow for Deploying APIs
The following illustration depicts a typical DevOps workflow for deploying API to 
Layer7 Live API Creator
:
DevOpsLifeCycle.png
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 
    one
     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 
      LAC_REPOSITORY_CONFIGURATION_URL
       option when you start API Server.
Team Development Best Practices
We recommend the following best practices when working as a development team using 
Layer7 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.