- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-18-2016 12:20 PM
I moved an update set today from my DEV environment to my QA environment however I noticed that my email notifications didn't make it over to QA.
Question 1: Does email notifications transfer over with update sets?
Question 2: If it does, what is best practice to fix this? Add the email notifications in a new update set in QA and then migrate back 2 Dev or Make the updates in QA and migrate over to the next environment QA2?
Solved! Go to Solution.
- Labels:
-
Best Practices
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-18-2016 12:47 PM
Answer 1: Yes, email notifications are included in update sets.
Answer 2: I don't know of a best practice. Depending on the situation, I've seen and used either of the following two approaches:
-- One Way --
- Create a new update set in Dev.
- Move the missed Email Notification update to the new update set.
- ** (You should be able to find that update in the Versions related records tab on the Email Notification record.)
- Retrieve that update set to the target environment and apply it (with the existing updates still in place there).
- Test thoroughly.
-- Another Way --
- Back out the existing update set (in QA in your case).
- Create a new update set in Dev.
- Move all the updates from the old update set to this new update set and move the missed Email Notification to the new update set as well.
- (Merge may help you with this.)
- Retrieve that merged update set to the target environment and apply it.
- Test thoroughly.
I tend to do the first method when the update is fairly simple. It does mean having to preview and commit more than one update set if you do it in each environment, of course. And if there are dependencies between the updates in the different sets, you'll get warnings when you preview that you have to handle. The second method can require a bit more work up front but then you know your update set has everything and there are no dependency issues.
The one thing I would avoid is trying to fix the existing update set and pull it up again. The problem is it may exist in a higher environment because someone has run 'Retrieve all update sets' there. If you don't catch that, the new fixed version won't be imported to that environment.
One thing I recommend to our developers is to regularly check your update sets as you develop. I generally try to do it daily because I'm old and tired and trying to remember what should be there and what shouldn't days or weeks later can be... challenging. You'd be surprised at how often things aren't where you expect them to be when you have a lot going on - which I'm guessing is the case for all of us.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-18-2016 12:47 PM
Answer 1: Yes, email notifications are included in update sets.
Answer 2: I don't know of a best practice. Depending on the situation, I've seen and used either of the following two approaches:
-- One Way --
- Create a new update set in Dev.
- Move the missed Email Notification update to the new update set.
- ** (You should be able to find that update in the Versions related records tab on the Email Notification record.)
- Retrieve that update set to the target environment and apply it (with the existing updates still in place there).
- Test thoroughly.
-- Another Way --
- Back out the existing update set (in QA in your case).
- Create a new update set in Dev.
- Move all the updates from the old update set to this new update set and move the missed Email Notification to the new update set as well.
- (Merge may help you with this.)
- Retrieve that merged update set to the target environment and apply it.
- Test thoroughly.
I tend to do the first method when the update is fairly simple. It does mean having to preview and commit more than one update set if you do it in each environment, of course. And if there are dependencies between the updates in the different sets, you'll get warnings when you preview that you have to handle. The second method can require a bit more work up front but then you know your update set has everything and there are no dependency issues.
The one thing I would avoid is trying to fix the existing update set and pull it up again. The problem is it may exist in a higher environment because someone has run 'Retrieve all update sets' there. If you don't catch that, the new fixed version won't be imported to that environment.
One thing I recommend to our developers is to regularly check your update sets as you develop. I generally try to do it daily because I'm old and tired and trying to remember what should be there and what shouldn't days or weeks later can be... challenging. You'd be surprised at how often things aren't where you expect them to be when you have a lot going on - which I'm guessing is the case for all of us.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-25-2016 11:49 AM
Hi Donnie~
Thanks for the explanation! This is very helpful!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-25-2016 12:04 PM
Donnie
One more question: So I noticed that my icon (pictures) didn't move to QA. How do I fix that? Where do I find it so I can update it in the new update set?