API server (greenfield)
If using the qaskx-cli command your project as code steps for a green field API server project can now be described using the steps 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 generate project command which will prompt you for values |
New project space on file system with devops.json file in .well-known directory |
| 3 | Using the project id request a new Configuration Identifier from CMDB | CI value |
| 4 | Use qaskx-cli rediops set command to set the CI value |
devops.json now has asset ID to link with CMDB |
| 5 | Use qaskx-cli generate openapi command to generate OpenAPI file from template |
A default OpenAPI file |
| 6 | Use your OpenAPI file editor of choice, such as Apicurio, to define your API | A draft 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 |
A default API server |
| 9 | Use your IDE to write required code into source code for each route shell created by template process | Executable API server |
| 10 | Commit/push git changes | Github updated with latest version |
| 11 | Write test units, or use CoPilot or similar to write test code based on OpenAPI specification | Test units created |
| 12 | Use qaskx-cli generate build command to generate build script and pipeline configuration based on rediOps information |
Build script and CI/CD configuration generated |
| 13 | Use qaskx-cli run activity -a build command to perform local build |
Local executable API server |
| 14 | Use qaskx-cli 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 generate deploy command to generate gateway configuration based on rediOps information |
Gateway configuration such as Kong GW or Traefik generated |
| 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 behind the scenes there is predefined templates for your organisatio to boot strap various development tasks. The above also does assume the code is “perfect”, while in real life there would be multiple iterations of code changes.
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 devops.json file 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 devops.json file so that you don’t have to assume locations or use conventions for each developnent tool.
If your tools change over time, then the devops.json file 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