November 15, 2018 | Kliment Klimentov
Setting up a Sitecore instance for local testing can be not only difficult, but also time-consuming. Dealing with extremely large databases or RAM requirements, setting up additional modules and servers, and taking in mind Sitecore license terms can be only part of the difficulties each one of your front-end developers might have to face when starting a new project. Not only that, because of Sitecore's OS requirements, Front-End Developers (FEDs) might be forced to use an Operating System like Linux or MacOS and/or tools that take them outside of their comfort zone.
reduces the time and effort of adding a new FED to the project to just installing a NuGet package and providing a network share. eliminates the need to install а test Sitecore instance for each of the front-end developers and provides a safe working environment, where FEDs can test their front-end assets without interfering with the work of Back-End Developers (BEDs) and possibly overloading their PC.
Often FEDs must wait for a build or trigger one, then wait for app pool recycle so they can see their changes applied to the Sitecore instance (a QA instance for example). What if the changes break the website? With , FEDs can see their changes straight away without passing over their assets to
Bottom Line: provides the flexibility to use all the tools a FED would use in their normal work on a local static site but see the changes on a Sitecore site.
Take for a test drive for 30 days and see what we mean.