API server (existing)

If using the qaskx-cli command your project as code steps for a existing API server project that has no redOps definition the steps to undertake are described in the table below.

Note 1: The table has only brief descriptions of the commands for brevity reasons. Please refer to the more detailed command documentation.

Note 2: The assumption is that the qaskx-cli setup prime has executed to initialise on your environment.

For background information, the rediOps definition is stored by default in file ./.well-known/devops.json

Step Description Outcome
1 Get a project code. As this is a first step, it is likely to be manual. Project identifier
2 On a command line use the qaskx-cli rediops new command which will prompt you for values New devops.json file in .well-known directory
3 Use qaskx-cli rediops set command to set the CI value devops.json now has asset ID to link with CMDB
4 Use qaskx-cli rediops set command to set the OpenAPI file location devops.json is now updated with OpenAPI file location
6 Use your OpenAPI file editor of choice, such as Apicurio, to modify your API Modified OpenAPI definition
7 Commit/push git changes Github updated with latest version
8 Use qaskx-cli generate server command to generate base API server code from template. Existing routes are not touched A default API server
9 Use your IDE to write required code into source code for each new route shell created by template process Executable API server
10 Commit/push git changes Github updated with latest version
11 Write more test units, or use CoPilot or similar to write test code based on OpenAPI specification Test units created
12 Use qaskx-cli rediops set command to define existing build script file location Build file location in devops.json
13 Use qaskx-cli run activity -a build command to perform local build Local executable API server
12 Use qaskx-cli rediops set command to define existing test script file location Test file location in devops.json
14 Use qaskxcli run activity -a test command to perform local test Local test execution
14 Commit/push git changes Github updated with latest version
15 Push to Github signals your CI/CD pipeline to run build and unit tests Build and test execution report
16 Use qaskx-cli rediops set command to set gateway configuration based file in rediOps Gateway configuration such as Kong GW or Traefik is linked in devops.json
17 Use qaskx-cli generate deploy command to generate docker (or podman) file based on rediOps information Docker file generated. Could also be a docker compose file.
18 Commit/push git changes Github updated with latest version

The above is simplistic, but demonstrates how existing projecs can be defined into the rediOps process. The above also does assume the code is “perfect”, while in real life there would be multiple iterations of code changes.

There is the qaskx-cli definition scan command to locate existing definitions and populate the rediOps definition.

The above table of steps has assumed that:

  • You have an IDE for coding and it is linked with git/Github
  • Github or equivalent is used and can be accessed via APIs and login exists
  • Git actions are used
  • Your TeamCity, Jenkins, CircleCI or CI/CD pipeline has webhooks to Github

If you have integration between your Github and CMDB, the CMDB can be updated with more information from the rediOps definition as the SDLC progresses.

If there is integration between your Github and your API catalogue and Mock servers, then automation can publish to the API catalogue and can create Mock server responses based on the OpenAPI. The information as to where various definitions or configurations are located is held within the rediOps definition so that you don’t have to assume locations or use conventions for each developnent tool.

If your tools change over time, then the rediOps definition can be changed as and when required. Versioning of the devops.json file is automatic as it is stored with your project and not outside