Currently, I am focusing extensively on Continuous Integration and Deployment (CI/CD) within the context of integration. My ultimate objective is to not only guarantee the safety of my integration processes during development and deployment but also to automate the process using a suitable set of rules.

In this context, I came across Vadim Klimov’s blog post titled “Enforcement of Compliance with a Style Guide,” which has inspired me to delve deeper into the topic of API linting.

https://blogs.sap.com/2022/10/18/api-contract-enforcement-of-compliance-with-a-style-guide/

I came to recognize the importance of using API linting tools and adhering to style guides. Consequently, I decided to incorporate Spectral into my DevOps pipeline to ensure that my APIs adhere to the required standards.

Spectral is a valuable tool for maintaining APIs, as it performs API linting by checking specifications against a custom set of rules and ensuring they adhere to defined structures. It provides a range of built-in lint rules, which cover a wide range of potential issues with your API specification. It also allows you to write your own custom rules, which makes it highly customizable. By integrating Spectral into my build and deployment process, I was able to analyze the results and make improvements to my APIs to ensure they met the desired standards. To test this integration, I created a simple example YAML file to establish a pipeline. The code for this YAML file is as follows:

trigger:
- master

variables:
  CONFIG_PATH: '$(Build.SourcesDirectory)/spectral.yaml'

steps:
- script: |
    npx @stoplight/spectral-cli lint "$(Build.SourcesDirectory)/SBU/spectral.yml" -r $CONFIG_PATH -o "$(Build.SourcesDirectory)/test-results/spectral-results.xml" -f junit
  displayName: 'Spectral Linting'
  continueOnError: false

- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '$(Build.SourcesDirectory)/test-results/spectral-results.xml'
    failTaskOnFailedTests: true
    testRunTitle: 'Spectral Linting Results'
  displayName: 'Publish Spectral Test Results'

The trigger “master” indicates that the pipeline is triggered when changes are made to the master branch of the repository. The pipeline contains a variable CONFIG_PATH that contains the path to the Spectral configuration file. In the first step, the script npx @stoplight/spectral-cli lint is executed to check the API specification. The configuration file is referenced via the variable CONFIG_PATH, and the results of the check are saved in the JUnit format in the spectral-results.xml file. If errors occur during the check, the task will mark the pipeline as failed.

Once my pipeline has successfully completed, the following output will be displayed:

The image depicts a pipeline run that was successful.

The pipeline has run successfully and a subsequent process could now deploy the API.

In case of an error, the following would be displayed:

The image shows a pipeline run that encountered errors.

This image displays the linting results along with an XML attachment.

My pipeline has failed and is recorded in my test run report. Spectral has determined the exact cause for me and saved it in a separate file. In addition to being able to monitor the quality of development, I can also ensure that the APIs are deployed only if they comply with my defined ruleset.

The integration of Spectral into my DevOps pipeline has enhanced the quality and standards compliance of my APIs. Encouraging the adoption of API linting tools like Spectral in DevOps practices is crucial to ensure high-quality and standardized APIs. Additionally, it alleviates the need to ensure that every developer has set up the required prerequisites locally and allows me to safely enforce my ruleset through the pipeline.

What measures have you taken so far to ensure the quality of your API development?