Creating documentation in a Continuous Integration/Continuous Delivery environment

Creating user documentation and online Help in a Continuous Integration/Continuous Delivery environment can be challenging for technical communicators and developers.

Below are Wikipedia’s definitions of these two practices:

  • Continuous Integration (CI)  is the software engineering practice of frequently integrating all new or changed developer code to a shared repository several times a day.
  • Continuous Delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently.

This means potentially there could be new software releases each day, and there could be a need for to update screenshots and Help content to reflect these changes.

Alex Soto of Cloudbees has posted a video of how he has automated his documentation updates, using Jenkins (a continuous integration tool), Asciidoctor (a text processor and publishing tool) and Gradle (a build automation system, similar to the Apache Ant and Apache Maven tools used in DITA publishing):

Automated builds and (command line) publishing was one of the popular themes at last week’s MadWorld 2016 conference. Andrei Essaoulov showed how kCura was also using Jenkins builds (and PowerShell scripts) with MadCap Flare to publish automatically. .

We’re likely to see more Technical Authors automating documentation publishing and integrating it with the development teams processes, and it promises to enable software developers to deliver up-to-date content efficiently and quickly.

Have you worked in this way? You can share your thoughts below.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.