Blog
Feydra Frequently Asked Questions
April 13, 2017 | Angel Uzunov
With Feydra, front-end developers can work the way they want, using the tools they prefer and are used to instead of being worried about Sitecore requirements. Feydra also allows them to commit their changes without the help of a back-end developer. Since the product release we've gotten a number of excellent questions from the community, such as:
Q: How do I install it?
A: Feydra is supplied as NuGet packages which contain the 2 DLLs and a configuration file that need to be deployed to the QA or design server (typically QA).
Q: Approximately how long does it take to set up a Feydra environment?
A: About 10 minutes.
Q: How is Feydra different than a headless CMS implementation?
A: Headless CMS strips the front-end away from the content storage and production task. Content is delivered via API instead of as components or fully formed pages. Designers typically use a JavaScript framework for building pages.
Feydra separates the activity of front-end development from back-end, but does not change the standard functionality of Sitecore. It leverages a deep understanding of .NET development to decouple the process, but not the actual application.
Q: What does my team have to do to get a Feydra environment set up?
A: Push 2 DLLs and a configuration file to their chosen environment (usually a QA server) and create a standard file share on the server for the FED to push changes to. Virtually every team already has this environment in place already.
Q: Do I need to set up dedicated CM and CD Sitecore instances for Feydra?
A: Feydra is planned for use on the environment where the actual front-end assets will be used - in a split environment case, this would be the CD instance.
Q: Should the initial setup/deployment of Feydra be done on CM and CD Sitecore instance?
A: The initial setup, in a split-environment case, should be done on the CD instance. If your internal Feydra box (or QA, or whatever internal machine they're using) has both CM and CD, in which case you’d probably want it on both so that your front-end developers could see their changes on both. Generally, Feydra is only needed on lower tier environments like Dev Integration and QA. Feydra should not be installed on Production instances.
Q: Is web-app supported by Feydra?
A: Azure Web Apps are supported by Feydra with a small exception - for now Feydra doesn't have enough access to create the initial user folders under the FeydraRoot folder inside the website root, so these initial folders need to be created in advance (for example by having a build step create them).
We've answered more Feydra questions on our Feydra Q&A or skip right to the best part and download Feydra to start virtualizing!
Q: How do I install it?
A: Feydra is supplied as NuGet packages which contain the 2 DLLs and a configuration file that need to be deployed to the QA or design server (typically QA).
Q: Approximately how long does it take to set up a Feydra environment?
A: About 10 minutes.
Q: How is Feydra different than a headless CMS implementation?
A: Headless CMS strips the front-end away from the content storage and production task. Content is delivered via API instead of as components or fully formed pages. Designers typically use a JavaScript framework for building pages.
Feydra separates the activity of front-end development from back-end, but does not change the standard functionality of Sitecore. It leverages a deep understanding of .NET development to decouple the process, but not the actual application.
Q: What does my team have to do to get a Feydra environment set up?
A: Push 2 DLLs and a configuration file to their chosen environment (usually a QA server) and create a standard file share on the server for the FED to push changes to. Virtually every team already has this environment in place already.
Q: Do I need to set up dedicated CM and CD Sitecore instances for Feydra?
A: Feydra is planned for use on the environment where the actual front-end assets will be used - in a split environment case, this would be the CD instance.
Q: Should the initial setup/deployment of Feydra be done on CM and CD Sitecore instance?
A: The initial setup, in a split-environment case, should be done on the CD instance. If your internal Feydra box (or QA, or whatever internal machine they're using) has both CM and CD, in which case you’d probably want it on both so that your front-end developers could see their changes on both. Generally, Feydra is only needed on lower tier environments like Dev Integration and QA. Feydra should not be installed on Production instances.
Q: Is web-app supported by Feydra?
A: Azure Web Apps are supported by Feydra with a small exception - for now Feydra doesn't have enough access to create the initial user folders under the FeydraRoot folder inside the website root, so these initial folders need to be created in advance (for example by having a build step create them).
We've answered more Feydra questions on our Feydra Q&A or skip right to the best part and download Feydra to start virtualizing!
Tags
Related Blog Posts
- How Feydra can keep you in your comfort zone
- <span style="text-align: left; letter-spacing: normal; text-decoration: none; background-color: transparent; color: #000000;">Setting up a Sitecore instance for local testing can be not only difficult but also time-consuming. Feydra eliminates the traditional serial implementation process and reduces the overall development timeline.</span>
- Edit Front-End Assets with Feydra
- Feydra is the answer to a common question: How can front-end developers start working quickly on Sitecore assets like CSS and JS files without having to install and run the entire Sitecore project?<br> <div> </div>
- How Feydra Improves Front-End Development for Sitecore
- Feydra offers a more efficient modern approach to front-end development workflow for Sitecore.
- TDS Classic How-To: Perform Unattended Installation of TDS Classic for Visual Studio 2017
- 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.
- Sitecore Security and Strengthening Your Sitecore Platform
- Improve the security of your Sitecore platform with these tips
- TDS Classic 5.7 - Lightning Deploy
- 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.
- TDS Classic 5.7 - Lightning Sync
- Lightning Sync allows both sync and quick push operations to use TDS Classic 5.7's new Lightning Mode feature
- TDS Classic 5.7 - Solution Wide Sync
- A simple new feature in TDS Classic 5.7, Solution Wide Sync makes a big difference when working with many TDS Classic projects in a solution.
- TDS Classic 5.7 - Lightning Mode
- 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.
- Sitecore Experience Accelerator: Missing Video Description
- <p>A fix for the missing Video Description field in SXA 1.4</p>
- RAZL Best Practices: Lightning Mode and Deep Compare
- 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.
- Azure Sitecore Deployment: Deploying to a Slot
- 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.
- TDS Classic Best Practices: NuGet Build Components and TDS Classic .user configs
- 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.
- Azure Sitecore Deployment: Adding Project's Code and Items to the Azure Deployment
- Modify the scripts so that the compiled LaunchSitecore site is also provisioned into the new XP environment.
- TDS Classic Best Practices: Bundle Packages, Delta Builds and Delta Packages
- Following TDS Classic best practices, like using Delta Builds and Delta Packages, can make the entire development experience run much more smoothly.
- Azure Sitecore Deployment: Adding Custom Modules
- 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 Best Practices: Validators and the Sitecore Package Deployer
- 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.
- Azure Sitecore Deployment: Preparing the Default Scripts and Packages
- Preparing the default packages for a Sitecore Azure deployment and extending to add a custom module to the install.<br> <br> <br> <br> <br>
- Azure Sitecore Deployment: Setting Up the Solution and VSO Build
- <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>
- TDS Classic How-To: Disable Automatic Code Generation
- 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.
- TDS Classic Sitecore Deploy Folder
- 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>
- TDS Classic Builds on Jenkins Build Server with NuGet Packages
- 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.
- Features to Improve Sitecore Development: TDS Classic Strikes Back
- 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 and the Virtual Sandbox
- 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.
- TDS Classic Features to Improve Sitecore Development
- 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.
- Deployment Properties and the Deployment Property Manager
- 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: A Front-End Assessment
- 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.
- Feydra: A Quick Start Guide
- A step-by-step guide for installing, configuring and, most importantly, using Feydra from the front-end.
- TDS Classic 5.6 Feature Spotlight - Prevent Deployment of Incorrect Assemblies
- 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 from the Front-End
- 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.
- FxCop Rules for Sitecore Helix
- Create TDS Classic Custom Post Deploy Step
- 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.
- TDS: The Evolution of Auto-Sync
- 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
- 3 Critical (and Common) Sitecore Wellness Issues
- 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.
- Sitecore Placeholder Fallback
- 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.
- Customizing WFFM in Sitecore 8
- 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.
- Robust MVC Rendering Exception Handler
- 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.
- Context Based Datasource
- 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.
- Predefined Roles and Creating Your Own
- What are the out of the box Sitecore roles, when should you make your own, and how do you do it?
- Team Development for Sitecore Webinar
- Our Sitecore MVPs Charlie and Sean recently did a demo of TDS to all Sitecore partners. We recorded the demo to share with the world.