Reducing the size of your releases is a great thing to do in order to improve the health of app. It’ll reduce the risk of bugs, simplify rollbacks and get your code in front of users quicker. It also makes for less stressful releases… no one likes to ship one month worth of code at once!
However it’s hard to know how to ship smaller things, so a lot of people don’t even try to do it. If you’re in this situation, here is a way to start.
Let’s say you are adding a new feature to an older section of your app. You look at the code and decide it needs some refactoring and more tests. Instead of doing the refactoring while building the new feature, do it before. Once the refactoring is ready, merge it into master and release it… and only then start coding the feature. Same thing if you need to update a dependency to add a feature: release the update before actually building the feature.
This is not much, but it’s in my opinion a good way to start thinking about splitting releases, which will help in the long run.
Since you scrolled this far, you might be interested in some other things I wrote: