veyepar: Tech writing in a continuous deployment world

Author(s):	Christine Burwinkle
Location	Crystal Ballroom
Date	may Mon 18	Days Raw Files
Start	16:50	First Raw Start	16:44
Duration	00:30:00	Offset	0:05:12
End	17:20	Last Raw End	17:21
Chapters	00:00
Total cuts_time	27 min.

http://lanyrd.com/2015/writethedocs/sdmwyf/
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf Tech_writing_in_a_continuous_deployment_world.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

Here at Atlassian, we’ve been moving ever closer to a world of continuous deployment for our software products. Five years ago, releases took months. Now, many products are releasing every two weeks at a minimum. In addition, the past year has seen features being deployed as soon as they pass testing. What’s a tech writer to do!?
In true agile fashion, the response to these challenges varies across products and writers within Atlassian. This gives us a breadth of stories and examples I can share about our experiences in this world. Here’s a high-level look at what I’ll share:
A brief discussion of continuous deployment: what does it mean, especially for tech writers and others involved in the process?
A look at some things that have worked for us. Making the mental shift from releases to features has been an absolute necessity. We’ve also had to change the tooling we use, the processes we follow, and the way we communicate. This journey has also forced us to consider what the documentation equivalent of an MVP (minimal viable product in Agile development) looks like.
There are a few things that haven’t worked out very well! Resource-heavy deliverables (like videos and tutorials) are really difficult to maintain. Communication also increases in importance in a rapidly-paced cycle. These and other areas provide us with some good lessons learned.
The jury is still out on a few experiments! Things like investing more heavily in in-app help and automating doc publication in tandem with code deployment are among the experiments we’re attempting to get better at this new world.

Comment:

production notes