End-to-end development of Swagger API docs, including Dockerization

I've known how to edit API docs in swagger for about a year or so, but as a solo writer recently I took taught myself the end-to-end process. Since I don't know any other information developers who've done the process end-to-end at my company, I taught myself the technology and occasionally asked my devs for help. Here's what I did, working on and off over the course of a few months:

-researched pros and cons of swagger annotations in the java spec itself or in a separate spec file. Went with the latter, even though at first I felt this violated single source of truth principles. (the build process was so precarious and difficult for in-java annotations that it wasn't worth my time)

-read the java code in order to author the yaml spec by hand. API handyman came to my rescue here: https://apihandyman.io/writing-openapi-swagger-specification-tutorial-part-1-introduction/

-Installed swagger-editor to get instant feedback on my edits.

-Created a web app to publish my docs using Tomcat.  Made some use of https://idratherbewriting.com/learnapidoc/pubapis_swagger.html

-Got feedback that I actually needed to publish my docs using Websphere Liberty Profile instead of Tomcat.  Created a WLP web app using this tutorial: https://developer.ibm.com/wasdev/blog/2016/02/17/exposing-liberty-rest-apis-swagger/. In theory this would have been easy, but the most difficult part was finding the right version of WLP to install on Eclipse marketplace; the versioning conventions just seemed really confusing to me.

-Got told I needed to put my web app in Docker. Fortunately, there were a couple other Dockerized web apps in our team I could use as an example, plus the Docker intro videos are really good (https://training.docker.com/introduction-to-docker). I successfully Dockerized my WLP app, and handed it off to a developer.

YAY!

Some new roles

I've taken on some new roles in my team recently:

Agile coach

I'll be the agile coach for a 3-month stint for my team.  We face BIG challenges in implementing agile, the biggest being:

-lack of tooling:  since we work in highly regulated industry, our tools are waterfall-focused, and jumping over to agile-focused tools is a huge approval process. We hope (*HOPE!*) to have better tools -- ie GitHub, Jira support for Agile -- in place by late 2017.

-team complexity -- Coordination across executives, researchers, offering management, sw dev teams, ux, etc, across multiple offerings across TWO companies (parent company/acquired company) that both have required, differing regulatory processes? Very very tough. Biggest challenge I see is at the moment, some upcoming projects lack epics/hills. My hope is that for the projects that DO have epics/hills, we can build out our stories/tasks so as to provide workable examples/templates for other projects.

In the meantime the program manager and I have cobbled together an awkward issue tracking process involving issue types, links, titles, and labels.  It's incredibly manual at this point. We'll hobble along until later in the year, when better Agile support will be available, and I'll be checking regularly with my scrum masters to see if we can make any improvements given the limitations.

Software Release Manager
At my company, there's a traditional documentation set that technical writers are responsible for,  and another set that developers are traditionally responsible for. But I have enough technical depth that I can contribute to the developer docs too (stuff like functional specs, SW design specs, etc), and so I am.  I've also taken over project managing these docs from my SW development boss.

This also means I'm working on defining documentation processes, since our docs are all highly interrelated and highly regulated. For example, helping to come up with a process for tracking and maintaining our third-party components in a 400-row-plus spreadsheet (that one was a bear!); defining and writing up in our wiki how to document unit tests and code reviews, etc, etc.