2

When I locally as a dev try to create a package with the sitecore package designer, it seems impossible to get all items dynamically, that are (source items dynamically) changed or created the last 60 days (or to get any filter to work at all).

My goal is to create a package to deploy the latest changes on dtep environments by the installation wizard "manually". All attempts to see created/updated items in the \sitecore\templates folder (for master db) fail. No errors are logged in the log file, neither i'm able to find any hints or errors somewhere in the network traffic log, neither with the browser's console log.

I am able to make this filter work for content items under any site's content tree. So why Sitecore is not happy to show me the created and updated template items? I'm looking in preview mode for the selected source, but also generating the zip fails (seems logically to me as preview mode isn't showing me anything as well).

When saving the designed package, and opening the package project's xml stored on disk now, I can see the templates folder is selected as search root, and the filter types CreatedFilter + ModifiedFilter is set to NotOlderThan 60. Strange enough, after editing this project with the package designer, and click the already selected Templates folder as search root in the package designer the search root is reset to the /sitecore/content/home item. When saving the edited project again, the search root is cleared in the package's project xml that is updated after saving the project in the package designer. It's not storing the \sitecore\content\home item's Guid... OK, it's not a deal breaker here, but I think thats weird too.

After multiple time-wasting attempts to get the package designer to work in this case, I gave up... is it really impossible? Why is this option to filter on the templates-folder available anyway, then? I can't find any info on the net either.

And why some item names (like Templates) in the search root tree (in the package designer source's screen) are green-colored? It must have some special meaning.

Only alternative I have left now, is to manually select each changed template with the "add items statically" option in the package designer.

Improve this question
5
  • 1
    Other than it taking longer to install, there should be no reason you can't select all templates items at your custom templates root folder (possibly User Defined). Since your code is dependent on templates existing, selecting all of them ensures your code/templates are a 1 to 1 match. Why are you pursuing this option?
    – jrap
    Commented Mar 2, 2018 at 14:08
  • @jrap 1. triggered after creating package that way for content changes 2. laziness for selecting them specifically 3. rather having efficient small packages that only contain the changes to be done on dtep environments.
    – Michael
    Commented Mar 2, 2018 at 14:11
  • On the other hand, what am I doing!? Is it that wrong not to include the full "user defined" folder? :P
    – Michael
    Commented Mar 2, 2018 at 14:14
  • 1
    For manual deployments like that, I would choose the entire User Defined folder, just to make sure you don't miss anything- a merge could alter the last updated date and you could miss it. There are automated methods for doing this, but can't be answered in a concise way for SSE.
    – jrap
    Commented Mar 2, 2018 at 14:16
  • @jrap, thanks, sounds correct indeed. Although I never choose the merge option on installing a package manually.
    – Michael
    Commented Mar 2, 2018 at 14:20

2 Answers 2

Reset to default
8

The answer below is based on the additional feedback in the comments.

Manually Creating Sitecore Packages For Install in Higher Environments

First, you should create two types of packages:

Foundational Items: templates, renderings, layouts, placeholders

We call these "Deploy" items (I see Helix refers to these as "Definition Items", which is likely a better name). These items have dependencies on the code that is deployed. These are items that typical Sitecore authors should not be touching.

Building this Package

Select the root item for all of these items.

  • /sitecore/Templates/User Defined
  • /sitecore/Layout/Layouts/
  • /sitecore/Layout/Placeholder Settings/
  • /sitecore/Layout/Renderings/

This is just an example structure. Focus on grabbing the root items.

When building this package, do not filter items, select everything.

Installing this Package

When installing the Foundation Items packages, choose Overwrite > Apply to all. This is a safe option because, again, these items have dependencies on your deployed code files.

Content Items

You could call this your "Content" package. It would contain any elements that are new since your last deployment. Sometimes you won't even construct this package and instead choose to create new items manually in the higher environments.

Building this Package

Select all items that you wish to promote, but don't choose everything.

  • /sitecore/content/MySite/Home/MyNewItem

Installing this Package

When installing the Content package, choose Merge > Merge All. This option will not disturb items that are not included in the package. It will, however, overwrite any existing items and add any net-new items.

Automated Options

There are several techniques for automating this process that involve a significant amount of work but are fantastic once in place. They require that you have some type of CI/CD framework in place: VSTS, Jenkins, TeamCity, Octopus Deploy- it's impossible to cover in this brief post.

TDS Classic

TDS Classic can automatically generate Update Packages. These can be installed in the higher environments with Sitecore Package Deployer or Sitecore Ship.

Unicorn

I'm not as familiar with Unicorn, but since it also serializes items to the file system, there are options for pushing updates automatically.

Improve this answer
4
  • Thank you for the extensive answer. I shall look into the automation options.
    – Michael
    Commented Mar 2, 2018 at 14:49
  • Do you mind updating the question to be more specific? Such as "How to build manual Sitecore Packages for deployments?"
    – jrap
    Commented Mar 2, 2018 at 14:55
  • @jrap - "choose Merge > Merge All. This is a safe option as it won't affect existing items in the content tree. It will overwrite any existing items, however" - can you clean that up/clarify? Sounds like a contradiction.
    – Don Cheadle
    Commented Jul 31, 2019 at 0:09
  • Will do, War Machine
    – jrap
    Commented Jul 31, 2019 at 0:46
5

The issue you are having is that the dynamic filters in the Package Designer work as AND filters. So by entering adding both a Creation date filter and Modification date filter the packager is searching for items Created AND Modified within the last 60 days.

Instead you should add 2 separate sources, once specifying the Dynamic filter with Creation date and another with Modified date. Once you have separated the filter sources you should be able to check the items that will be included in the source preview.

Make sure you install the package with Merge > Merge All option rather than Overwrite for this type of difference package.

I would generally recommend automating your CI/CD process though rather than manually creating and deploying packages (or code).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.