@Mukeshkumar,
There is no simple answer to this question. In some cases, you may be provided guidance by security or auditing standards in place for the machine. In one environment I worked in, we were required to have important and critical security-only updates applied to machines within 60 days of their release by the vendor. This was a policy put into place by another team that did Risk Management and compliance across the IT department of the customer.
In some situations, maybe applying all packages all the time is the appropriate action to take, but, depending on the distribution you're using, a new package may bring significant changes with it. This may not be the most desirable activity or state to apply to the systems you're managing.
I think what you really want is not a "how to apply patches" or "which patches to apply", but instead a standardized method of managing a system's lifecycle. For example:
All security updates will be applied to systems within X days of their release.
Systems will be updated to the latest product update release within Y days of product update availability.
Maybe security updates is within 30 or 60 days of release. This would allow you to apply these updates to any upstream (non-production) environments to validate that they do not cause an issue with your applications, hardware, or system operations.
Possibly an update release policy would be with 90 days, so that, just like those security updates, you can apply the update relase (eg. moving from RHEL 7.5 to RHEL 7.6) to those upstream environments prior to applying it to your production systems.
Your lifecycle management standard could also address making configuration changes, the process through which updates are validated prior to being published to production systems, how systems are provisioned, how systems are decommissioned, and, finally, what has to be documented in order to have a system exempt from this process. Once you have this documented, you can get feedback and approval on it. That way, if you update something and it all breaks, you can point to the agreed upon lifecycle management doc and say "I followed the agreed upon process." Plus, once you get regular about doing these activities, it will start to be a routine and other teams (like app development) will be both enganged and aware of what's happening on the systems operations side of things (which is a benefit long-term).
-STM
