Project documentation is one thing developers do not like to think about but it is necessary for others to use the software. There are several approaches to project documentation where it is either stored in the source code repository and/or some kind of project web page, e.g. in a wiki. It is often hard for different groups of people to find the documentation they need and to maintain it. I want to show an approach to store and maintain the documentation in one place and integrate it in several other locations.
The project documentation (not API documentation, generated by tools like javadoc or Doxygen) should be version controlled and close to the source code. So a directory in the project source tree seems to be a good place. That way the developers or ducumenters can keep it up-to-date with the current source code version. For others it may be hard to access the docs hidden somewhere in the source tree. So we need to integrate them into other tools to become easily accessible by all the people who need them.
We start with markdown as the documentation format because it is easily read and written using a normal text editor. It can be converted to HTML, PDF and other common document formats. The markdown files reside in a directory next to the source tree, named
documentation for example. With pegdown there is a nice java library allowing integration of markdown support in your projects.
Integration in your wiki
Often you want to have your project documentation available on a web page, usually a wiki. With confluence you can directly embed markdown files from an URL in your project page using a plugin. This allows you to enrich the general project documentation in the source tree with your organisation specific documentation. The documentation becomes more widely accessible and searchable. The link can be served by a source code browser like gitweb:
http://myrepo/git/?p=MyProject.git;a=blob_plain;f=README.md;hb=HEAD and is alsways up-to-date.
Integration in jenkins
Jenkins has a plugin to use markdown as description format. Combined with the project description setter plugin you can use a file from your workspace to display the job description. Short usage instructions or other notes and links can be maintained in the source tree and show up on the jenkins job page.
Integration in Github or Gitlab
Project hosting platforms like Github or your own repository manager, e.g. gitlab also can display markdown-formatted content from your source tree as the project description yielding a basic project page more or less for free.
Using markdown as a basis for your project documentation is a very flexible approach. It stays usable without any tool support and can be integrated and used in various ways using a plethora of tools and converters. Especially if you plan to open source a project it should contain useful documentation in such a widely understood format distributed with your source code.
4 thoughts on “Centralized project documentation”
Markdown is pretty nice if the documentation is manpage sized (could even be converted into one with Pandoc) but really starts to show its limitations with multi page manuals with links back and forth. Sphinx really rocks in that department but unfortunately its based on ReST instead of a pimped Markdown syntax.
But in general I agree, manage docs inside the source tree.
Could you elaborate a bit more on the limitations with larger manuals?
Let’s take https://docs.readthedocs.org/ as an example. This would be possible to do with Markdown but pretty cumbersome without good automatic indicing suppor, cross-referencing is difficult, API integration and helpful elements such as warnings and notes.