Context

Have you ever argued with your teammate that some feature is finished and ready for production deployment? I faced it a couple of times from both sides of the roadblocks.

This situation is caused by a different definition of done definition. So let’s break it down into pieces.

When we could say that feature is finished?

There would be as many answers as the developers you asked. So I just want to show the levels that I spotted during my career. Let me clarify one more thing - we will be talking about production-ready software. So all things I describe do not apply to e.g. prototype of an application.

0. It’s implemented

I hope that this point shocked you. I had the same feeling when I saw that someone is deploying code (that was implemented 10 min ago) which is not been tested at all. Someone could say, that sometimes you need to deploy a hotfix to production. My answer is - something goes wrong in the development and internal tests process when you need to hurry to deploy a hotfix :)

1. It’s reviewed

I am ashamed that I said something similar one time after some CI/CD change I was doing did not work. I was inexperienced at that time… but that’s not an excuse. Remember, someone’s approval of the merge request does not absolve you of responsibility for the code.

2. It’s tested locally

For me, it’s something obvious, but I still see cases when untested code is deployed to prod. Remember, it’s always easier to discover bugs in the code you develop instead of debugging code that is running on prod for a couple of weeks or months.

3. It’s unit tested

I know that still people think that implementing unit tests is a waste of time and because of that unit tests are very often postponed or not implemented at all. For me code that does not have unit tests, it’s not finished.

4. It’s tested internally - by someone else that author

When you are reaching this point daily - it’s quite good we could say. When you are working on some application for a long time, then you could test “happy paths” only. Having someone else that could double-check it is a game changer.

But still there is a couple of things that could be improved

Let’s discuss them below.

5. You have logs with correct levels and additional metrics prepared

For sure, you would be observing how your new feature behaves on production to revert it when someone bad will start happening. To do it as fast as possible, prepare these logs even before deploying your code. In some complex cases, some additional metrics also would be welcome.

6. You are having feature-flag that covers things you developed

You will be sleeping well knowing that you could always revert your change without the need for reverting code and redeploying your apps. This approach would let you deploy it gradually e.g. per customer instead of doing “big bang” deployment.

7. Inform all people that could be interested before deploying a change to production

By doing this you are giving someone a chance of spotting things that won’t work or in the worst case will crash your application. Believe me, it could prevent a lot of problems in your daily work.

When you work for someone else. You should think about informing people that are making decisions about the app you are developing.

Some of them could be done even before you will start implementing new code

Fixing things without touching code will allow you to reduce the time of implementing it. I will present a couple of things below.

8. Prepare a couple of designs for your feature

Thanks to that you will be able to pick the best approach for a solution taking into consideration:

• business requirements
• technical limitations

9. Try to find a solution that lets you save time maintaining it over time

I saw such a situation very often… Someone implemented code that was doing what was intended to do. But it wasn’t prepared for any change that customers asked for in the future. I think this is one of the most underrated approaches for preparing code that could be easily maintained in the future.

In other words: if you don’t have a solution that considers the maintenance stage - don’t implement it. You will lose your time when implementing it and after that when fighting with problems. You should spend more time on a design to decrease the time needed for implementation.

10. “Implement code that could be removed very easily”

I don’t remember when I heard that rule, but it helps me implement code that is simple and generic. That gives me a couple of advantages. I can reimplement the entire code by removing it and simply implementing it from the scratch - using interfaces helps you establish contracts between modules. I am not afraid because of implementing something new, because I know it could be easily replaced by the next iteration of an idea - that would be improved thanks to the experience we gather.

11. Discuss your idea with more experienced developers

Before you start implementing new things. You could write it down in the task tracker your team is using. Then you can simply ask your teammates for some advice. When you are having people that are working on that system way longer than you, you will be getting a lot of pro tips about the module/feature you want to work on. Spreading knowledge about the system inside the team is very important.

Summary

In this post, I just gathered a couple of things that could help you build your own feature deployment checklist. Hope you would find something useful :)