Tiny struggles

Always hacking something 🧑‍🔬.

My release checklist for chrome extensions

Many products can be updated very quickly. You spot a bug, you push a fix in next 5 minutes, sadly for chrome extensions it’s not like that.

When you update a chrome extension in the chrome web store you submit a package that then goes through a lengthy review. It can take multiple days and during that time you can’t update a newer version, for example if you find some bugs.

That means that you better deploy solid code otherwise your extension might be broken for multiple days (if the new review takes similar amount of time).

Maybe in some cases of a simpler extensions the review can be simpler, but in the case of my extension watchlimits it’s always been painfully slow!

So how do I make sure that what I release is solid?

I go through a checklist.

Here it is:

Checklist what to do before releasing:

  • clean up debugging statements
  • think about main happy and unhappy paths and see if they are covered
  • update the manifest
  • build prod version of the extension (I develop in dev mode)
  • test manually
  • run tests
  • run storybook tests
  • click through storybook stories - all should work and look fine
  • install extension from unpacked version in chromium (new user experience)
  • test manually
  • commit any code changes
  • upload!
  • write a changelog

Hard lessons

Cleanups and unhappy paths

The cleanups are pretty self explanatory, no one like chrome extensions to spam their console. But what about thinking about the unhappy paths?

I have the “unhappy paths” on my checklist, because building new features is so exciting it’s really easy to forget about major “unhappy” aspects of the feature! But those matter too! Examples would be - extension is offline or there is no data, etc…

And that can add a significant amount of coding so I do this before any serious manual testing.

Testing & storybook

As your software grows in complexity, it’s easy to miss that something is broken, so testing is key.

It could be manual testing or automated testing. Great automated testing of mostly frontend products is pretty hard. I try to make sure to have good unit tests, but I also rely on storybook which is incredible for making sure that main subsets of my app are working fine. I also love it for isolated development. I highly recommend trying it out!

Before I release a new version I would look through storybook stories to make sure that everything looks good.

storybook

For manual testing there is nothing better than recording a video demo. Because it will force you to go through the whole functionality end to end.

Not only you will make sure that the UX is good, you will easily spot all the bugs that you wouldn’t spot otherwise.

Fresh user installation

If your extension relies on some persistent data, it’s really important to check if the extension will work for new users as well as existing users.

I have made this mistake before! I was developing the feature iteratively and didn’t realize that some functionality required some data to be already persisted and that resulted in a broken experience for new users. Not the best first impression!

Because of that I pack the extension, unzip it in a different folder and run it a separate browser as a fresh installation.

fresh

And then I manually test it again…

Changelog?

My app doesn’t have a built in changelog in it, but writing about any big feature release helps me better articulate the value of the feature and also explain how to use it. I can use it for the promotion or as a knowledge base for the users.

Time will tell if it’s a worthwhile effort!

Conclusion

I’m an indie maker, so I don’t have an infrastructure team or time for building a complex CI pipeline or automating all the testing.

What about you? Are you careful with your releases? Do you have any recommendations to improve my checklist?

Check out my latest project Watchlimits
Watch time insights and limits that work for you!
This is my mathjax support partial