Recently, our Head of Implementation Services was attending a developer conference where he met an IT manager who worked for one of the major corporations. The IT manager told my colleague that one of the responsibilities that their IT team has is deploying and maintaining IT environments for other teams within the company. For example, one day, the IT may be asked to set up servers for a certain product that the QA dept. needs to test, and another day they might need to configure an SQL database for the internal helpdesk.

Each deployment needs to be documented for internal use. For example, after servers for the QA dept. are up and running, the IT team needs to document the IP address and port of each server so that the users within the QA dept. would know how to work with the environment. Quite often, the IT team needs to update the configuration (for example, if a new server is added or the server’s port is changed). This means that the deployment documentation has to be updated too. Well, theoretically, because more often than not, the IT team is so busy that they just don’t have time to maintain both the actual IT environments and the associated documentation. This causes a lot of mess because people (maybe even other IT team members) try to use the servers and databases based on the deployment documentation which is apparently outdated, and obviously things go wrong.

This is a quite typical situation that we see in many places. So we’ve built an application for our content automation platform that generates both configuration files and documentation automatically from the specs.

Suppose that you wrote a topic that documents a configuration of the Apache server. It includes the server root, port, document root, and other parameters required by an Apache server. The topic also contains a list of Apache modules to be enabled for this particular deployment. If you’re an Oxygen user, you can set up your authoring environment in a way that lets you pick up required modules from the pre-defined list instead of typing their names manually.

topic2config_topic

Then you run the application that we’ve written for our content automation platform, and an HTML or PDF documentation and an Apache configuration file is generated automatically from this topic (it’s not a fake, this configuration file was actually generated automatically):

topic2config_config

The same idea can be used to generate configuration files for other purposes, for example, configuration files for MySQL Server or MS SQL Server configuration files out of specs.

Click here to see it in action!