Hedgehog is headed for London! Our SUGCON Europe team talks sessions, SUGCON memories and shares tips for getting the most out of the conference. <span style="white-space: pre;"> </span>
Hedgehog, a digital consultancy engineering high - performance, multi-channel solutions, today announced the release of a brand-new product called Avtor, a part of the Team Development for Sitecore Essential Collection.
Development of features and components requires a set of Sitecore items to be packaged - things like renderings and templates. With TDS Classic, Sitecore developers can automate the packaging process.
The TDS Classic version for Visual Studio 2017 is installed a bit differently than previous versions; the process is separated in two parts and performed by two different installers.
Lightning Deploy Mode can be used to enable Lightning Mode for all deployments that utilize the TDS Sitecore Connector in their configuration, improving their speed and efficiency.
Lightning Mode helps to improve the speed and efficiency of both deploy and sync operations. This enhancement is achieved by modifying how item comparisons are performed.
From scheduling Razl scripts to sync changes between Production and QA environments to keeping logs from scheduled Razl scripts, our team has a few tips and tricks to make the Razl experience even better.
Setting up Azure staging slots, so the next release of our project can be placed there, allows us to deploy the new code to a private website (the slot), and test it before pushing it live. We are going to script this process to make it easier for the devops team to automate.
There are certain systems and processes that you can put in place to make a TDS Classic project run more smoothly. We're highlighting the best practices that our team recommends for getting the most out of TDS Classic.
Modify the previous install so that the initial install contains the Sitecore Package Deployer module. It is an excellent way to enable continuous integration to the website.
TDS Classic can be used in many ways, but the goal is always the same: make development (and developers lives) easier. Whether it's using the Sitecore Package Deployer or using validators, following best practices can make your entire experience run much more smoothly.
<p>The first in our series on setting up a Sitecore instance on Azure, with an initial deployment that includes custom built modules as add-ons to the setup.</p>
When building an .update package with TDS Classic, the build might fail with no additional information. From increasing log verbosity to using validators, there are ways to minimize or prevent this type of error.
Code Generation is automatically triggered after every change in the TDS Project tree. If a project contains many items, users can disable this feature for their convenience.
Sitecore Deploy Folder is a setting, located in the build tab of the TDS Classic Project's Properties page, and used to tell TDS Classic where the webroot is located.<br>
Our simple scenario includes 2 developers using TDS Classic and checking-in changes to source control. The Jenkins build server takes the changes and performs the build, and then deploys the created package to two Sitecore environments.
Each and every feature in TDS Classic is aimed at helping developers. Whether the feature is out front or running quietly in the background the goal is always the same: make the development experience better.
Feydra virtualizes all front end assets (css, js & cshtml) of a Sitecore instance. With Feydra, front-end developers can commit their changes to Source Control without requiring the intervention of a back-end developer. We call it a virtual sandbox.
Answering a number of excellent questions we've gotten from the community regarding Feydra, including how long it takes to set up a Feydra environment and how to install the product.
Each version of TDS Classic comes with the same goal: to make Sitecore development and, by extension, developers, lives easier. Every feature in our products is aimed at making the process better - some of these features aren't quite as well-known as others, but they all help smooth and improve the development experience.
When working with TDS Classic, you will eventually need to deploy your items to a Sitecore instance and you might not want the default behavior of every item in your TDS project deploying every time. This is where the TDS Sitecore Deployment Property Manager comes in!
Feydra allowed me to start building the front-end in a very short time with no Sitecore experience, and it let me use tools that I was comfortable and familiar with.
This feature, new to TDS Classic 5.6, will prevent a solution from deploying unless all assemblies (except the excluded assemblies we allow you to specify) match what exists in your webroot.
Feydra eliminates common roadblocks for designers and front-end developers working on Sitecore projects by getting them up and running more quickly and allowing them to use the development environment and workflow tools they prefer.
Team Development for Sitecore Classic version 5.5 allows developers to add post deployment steps to to their deployments and update packages. TDS Classic has used post deployment steps internally to perform a number of useful functions. Many of the developers using TDS Classic have requested the ability to add their own post deploy functionality. With the release of TDS Classic 5.5 in early 2016, this functionality is now available.
New to TDS 5.5 is the ability to create and consume NuGet packages in your TDS project, allowing developers to capture their Sitecore items and easily distribute them across multiple teams.
Auto-Sync has been described as a new feature, but in reality has existed in TDS since 2010 and has taken a new form in TDS 5.5, due to be released March 22, 2016
There are a lot of factors that can adversely affect Sitecore and its performance. There a few common errors that we almost always uncover when running a wellness evaluation.
If you don't want to use a third party development tool for your config transforms, I have good news. Config transforms are supported natively within TDS!
When implementing Sitecore websites, we sometimes run into a situation where the Content Editor wants to personalize or A/B test components that are common to multiple pages in the site. A good example of this is the header and/or navigation components. The problem we run into is that the components need to behave the same on all pages and it would be very difficult, if not impossible for content editors to maintain these components on all pages on the site. I have seen a few ways of solving this problem, but most solutions had some drawbacks that limited the capabilities of the content editor.
WFFM is a great tool for allowing content editors to build custom forms. The main issue with WFFM is that it doesn't always generate the HTML we need for the site. This blog post shows how to customize the HTML in different ways for each sub-site.
While working on a recent Sitecore MVC implementation, I started to think about how Sitecore handles errors in the MVC components on a page. In past implementations, I had added a processor to the mvc.exception pipeline to route the user to the error page for the current site. This works reasonably well, but I began to notice a few drawbacks.
Creating and maintaining your datasources in your content tree can be challenging. This blog post shows how to get Sitecore to help organize the datasources.