There are a few things you can do to make your life easier. The first is to fully understand the Red Hat release life cycle.
One thing I suggest to people using Satellite is to keep a copy of the available channels in a local file:
# satellite-sync -l > channel_list
This will save you the hassle of having to wait for satellite-sync to communicate with RHN to download the list. After adding channels to the download rebuilding the list is a good idea, as a "p" get's added to the channels you are already syncing.
In addition running the Satellite Sync on a nightly basis, will not hurt and can make things much easier. However please note that the sync will start anywhere from 1am to 2:30am in your local timezone, and may run for any length of time after. Be sure that any backups of the Satellite Database do not happen at a similar time. If need be you can reduce the sleep time in the cron job. This is put in there so that everyone isn't hitting RHN at exactly 1am in their respective timezones.
Ok now onto what what you have asked about. Unfortunately due to the differences in every organization using Satellite there isn't a way to create a all encompassing "best practices." It is often suggested however that organizations using clone channels that they consider a Dev/Qa/Prod type of life cycle. Where the Dev channel is sync'd to the RHN channel (which sync's on a nightly basis) on a specific timeline, then the Qa and prod are updated at a point in time later should the Dev pass all requried update testing. The Prod channel would then be updated when the Qa channel passes it's testing. Let's say you update the Dev channel on a monthly basis, you would then update the Qa channel one week later against the Dev channel unless there is an issue with the updates. Then the Prod channel would be updated a week after that unless there was an issue. Two problems emerge one, how to handle emergency updates for critical vulnerabilities and how to handle organizational friction. Two, many organizations want the level of control this three tier method gives, however many may not be willing to adhere to the 1Month/1Week/1Week schedule. Thus it may be more suitable for your to have a one or two tier system modeled in a similar manner.
It is also suggested that all additional packages be placed into child channels. Thus if you have a version of puppet you use, place it into a top level channel of your own creation, then create a clone of this channel as a child of the Dev channel. You will also need to create a clone of this child for both Qa and Prod, which the initial clone coming from the next level up (Dev -> RHN, Qa -> Dev, Prod -> Qa). This is important because it make the UI a little more streamlined if you need to perform a channel update using the UI. It is also suggested that you clone the RHN-Tools channel for all of your clone channels.
Also you may have situations where groups within your entity require that all of their systems be RHEL X.Y and no newer. While this is easy to do using packages such as spacewalk-create-channel (sorry link is to a document available only to RH subscribers), your groups will be at risk because they will not be getting the latest updates. This is where understanding the Red Hat release cycle is important, and understanding the Vendor release policies. For instance many people assume SAP will only work on RHEL A.B where they actually say in their documentation that they will work with any presently supported version of an approved Operating System. In addition you could "cheat" and not update the package which updates the /etc/RedHat-release file in your clone channel, but you run the risk of support challenges later, thus it is not recommended.
When naming your Clone channels it is important to remember that Satellite will display them using a simple string sort. Thus if you want your channels to be easy to understand in the UI, name them in a manner which works with a simple string sort. I recommend people name their clone channels with "clone" or something similar at the start, and that all associated child channels follow a similar schema. The decision to add architecture to the name is up to you. Thus a clone channel may be named as such clone-rhel-5-x86_64, or mycompany-rhel-5 (if I use one architecture in my organization). I may also chose not to put RHEL in the name. It is best that you always include enough information to fully understand the nature of the channel.
When you create clone channels you cannot perform kickstart installations against clone channels unless you create kickstart distributions within Satellite first. The directions in the link assume you are importing an ISO, thus you can skip the first half of step 5. When you copy the ISO to your filesystem, you can delete the packages directory. The key thing to remember is you will need to create a kickstart distribution for every version of RHEL you plan to clone. In addition each version of RHEL has a slightly different bootloader and thus it's important to use the latest ones where possible. However if you are planning to use a "frozen" clone of RHEL 5.6, it is not suggested to use a 5.7 installer. When naming your kickstart trees one suggestion would be clone-rhel5-u1, with the number after the u corresponding to the point release. Thus 6.0 would be u0, and 6.3 would be u3. You will not need to import a kickstart tree for every clone channel. The best place to get the ISO is to download it from Red Hat, you can get away with just downloading the first CD or DVD. I have not tried any of the other images so I can't tell you how well they do not do not work.
Lastly, wherever possible script everything you can in terms up updates using the API. Humans are lazy and make mistakes, and often the UI requires a second "confirmation" click which I have watched people skip many times thinking their action was complete. In addition the organizational friction I mentioned above with regards to udpate cycles could be overcome via the API. For instance once a month you could update your Dev channel against the RHN channel using the API. Then you would send everyone an email. One week later the QA channel would be updated against the Dev channel, again everyone would be sent an email. One week later the Prod channel would be updated against the Qa channel. If your channel names are consistant enough or you use consistant names throughout your api script can be generalized to accept a to and from channel such as:
# update-channel --to prod --from qa
This would then update the following channels: prod-rhel5-x86_64 and qa-rhel5-x86_64. Even smarter it would update all child channels as well.
Hopefully that get's you a little further.
*note: My day job is with Red Hat, but the above does not represent any official support information. The above information is only a suggestion to help you better understand RHN Satellite.
Best Answer
NOTE: Red Hat Satellite 5 is still based on project spacewalk, but the next major release is moving to Katello, Pulp, Puppet and Foreman.
Although the SuSe management server is also an implementation of the open source project spacewalk I don't how similar that is to Red Hat's Satellite server implementation and how either of those compare to the vanilla open source project.
Errata advisories are Red Hat's way to distribute updates. It is safe to assume that the concept if similar to how others implement it.
You can consider a single errata advisory as a "container format" that contains the update to address a bug or security issue for one piece of software. Nearly always a single errata advisory results in more then just 1 single updated package, hence the need for a container format.
Second an errata advisory often impacts not only a single flavour of one major RHEL release, but multiple flavours i686 and x86_64 on RHEL 4, 5, 6 and RHEL7 server and workstation releases.
If you take for instance the Critical Security update for Shellshock RHSA-2014:1293-1 you'll see that the errata advisory contains a number of standard headers,
Followed by a human readable description of the issue(s) addressed in this errata advisory and the list of updated packages.
In this case the updated packages are a bash Source RPM and a number of regular binary rpm packages: the actual
bashrpm package, abash-debuginfopackage andbash-docfor each architecture and major release mentioned in the Affected Product list.The operational concept of applying errata is that you want to report on security vulnerabilities that are patched and bugs that are fixed, rather than package versions that are installed.