At Noveo, we don't just build software — we build systems. For anything. For everything. From enterprise platforms to... a book.

Once you're wired for engineering, you see processes everywhere. Programming is more than a profession — it's a mindset. And that mindset doesn't switch off when you close the IDE.

Kirill, Senior Developer at Noveo, took the idea of automating routine for the sake of creativity quite literally: he applied Git, CI/CD, and automation to his own writing process — and turned a narrative workflow  into a predictable pipeline.

The same logic applies to any business: start with the right question, and optimization follows.

Some time ago, I came across a funny observation online: as a programmer, you're essentially just editing text files and getting paid for it. Of course, working with code is perceived as something quite different from writing fiction or non‑fiction, but in essence, these processes are indeed very similar. As it happens, in my free time from fixing work text files, I enjoy doing the same thing as a hobby — as a writer. And a couple of years ago, a simple idea struck me: why not apply some of my work approaches and tools to my passion? Here's what came of it. 

Comparing Books and Code 

Let's look at the process of writing a book, setting aside its literary value and focusing instead on what it has in common with building a software product. So, we have a set of text sources — a book or code — which we try to improve step by step. Anyone who has tried writing off the top of their head knows that it's hard to achieve not just perfect, but even acceptable quality on the first try.

Just like in product development, writing a book has its own technical debt - as you go, some paragraphs and chapters naturally end up needing a rewrite. And the similarities don't end there. While certain phrasing or stylistic choices might still be a matter of taste, missing commas, misspelled or misused words are real bugs that directly affect the quality of the work. 

So, writing a book turned out to have a lot in common with coding: incremental development, the need for refactoring, and the need to find and fix bugs. For the latter, it would also be nice to add at least a couple of QA readers to the team of one writer‑developer, because re‑reading your own work clouds your vision just like testing your own code does. I could review task trackers or wiki tools for keeping track of plotlines and characters here, but everyone already seems to know how and why to use these undeniably useful tools. So what do I suggest using at this stage? The answer is simple — Git! 

How I Use Git 

Any developer who has looked beyond git push or git merge knows that Git has an incredible number of capabilities. So I'll only talk about what I use myself for working with fiction texts. I'm sure you can think of many other useful techniques. 

As you know, Git is a version control system, so it's no surprise that I use it primarily for version control. Usually any of my works goes through several rounds of editing, and tagging with git tag helps track what appeared in which version of the text. This becomes especially useful when you give the book to someone with editing rights and then review what they've changed. And if you manage to convince your alpha reader to visit GitHub, they can offer their edits as a pull request — which is even more convenient. Incidentally, for fiction works, when tracking changes I recommend using git show --word-diff or git diff --color-words, because from Git's perspective, an entire paragraph is a single line. 

back circling over this place. Perhaps the unexpected scanner{+s+} [satellites]  that
crossed the sky remained the most exciting and talked-about event the
town had seen in the last decade. Back then, no one ever found out
why the [scanners]{+they+} were flying around or whether {+they+}
found anything, and now these <<archaeologists>> have shown up and also
won't say what they expect to find in the sand. Such interest could
have [too] stirred up the locals, but the ingrained since birth

Example of a typical diff after edits 

Another way to make your life easier with Git is to store texts. I know there are many services with automatic content sync, like Google Docs, but I prefer to work in a familiar Word window with a local copy of the book. I recall George Martin, who writes (or, by all appearances, no longer writes) his works in DOS using the WordStar editor. Everyone has their own preferences, and that's fine. 

So for those who keep texts on their computer, Git provides a way to store copies both on the server and on other machines. The key is not to forget to commit and push! And regular git commit offers another nice advantage — it's very easy to track your progress. Just run something like git log --pretty=format:"%h - %ad : %s" --date=short, and you have a clear list of days when you worked on the book and when you didn't.

Here I can check what I was doing back in 2020 

Git can even transform the approach to writing itself. Suppose you decide to write not along a fixed plot, but let the characters roam free and see where it leads (the so‑called gardener's approach). With this method, you can easily end up in a dead end (hello again to Martin). If you have just one file with no intermediate copies, you'll have to dig the failed plot out of the text while making sure no stray hints or traces remain. A commit history with clear notes turns such a rollback into a matter of minutes. Of course, I don't wish major rewrites on anyone, but being prepared for them already removes half the pain. 

Setting Up a Publication Pipeline 

Not so long ago, I ran into another annoyance. The time came, and I was ready to trust the alpha version of a new book to my first readers. Previously a simple PDF was enough, but this time I was asked for a format suitable for an e‑reader. Caring about my QA, I quickly downloaded calibre and, through its simple UI, learned to compile books into epub/fb2 formats. And of course, as soon as I sent the first versions to recipients, I spotted a couple of annoying typos and missing commas. I fixed them and generated another 3 files. Then I remembered that I'd forgotten to update the cover. Hello again, another 3 generations! That's when I realized I didn't like this at all. The analogy immediately clicked: compiling source text into a set of build artifacts. In other words, I just needed to set up CI/CD for my book! 

Everyone's pipeline setup will differ depending on how you work with text and how you prepare the layout. Some might use Markdown and generate artifacts with Pandoc. Others might not think about layout at all and outsource the whole job. I wanted to set up CI/CD without changing my familiar development environment. So the task was this: Word => PDF, Epub, FB2 with cover and metadata. 

First, I studied calibre and, to my great satisfaction, discovered that it has a console version, so my desire to reduce everything to running a single script turned out to be achievable. And here's the command that made me happy: 

ebook-convert.exe input.docx out.[ext] --authors CoolAuthor --title CoolBook --cover CoolCover.png

Set different exts (pdf, fb2, epub) and calibre figures out how to generate the output file. It seemed simple — come up with a config to hold publication parameters for different books, write a Python script around it. Well, more precisely, check what AI generated for me. I'd never let AI write books for me, but scripts are a different matter. And speaking of AI — it's also very helpful in writing: you can discuss lore details with it, and check questionable passages for grammar. 

So the script works, but there's a problem — PDFs come out in the wrong format, and the input parameters don't override the defaults. Who would have thought that writing books would run into such a familiar phenomenon as third‑party library bugs? But then docx2pdf came to the rescue — with it we convert the docx source to PDF as if we'd pressed "Export" inside Word. Add a condition to the script, and it's done! In the future, I only need to add artifact upload to a server so readers can always get the freshest version.

What conclusion would I like to draw? I don't think the solutions described in this article will be practically useful for many readers, but I encourage you to look at routine processes from a new angle — and perhaps discover a way to bring a little more automation into your own life.