Sitecore Experience Accelerator (SXA)

One of the complex elements of development and Sitecore development in particular, is how to get your Development Team (DEVs) and Frontend Development (FEDs) teams working in parallel. Normally, your DEV team will put together the server side code, views and renderings and then pass this off to the FED team to style. This in itself presents a quandary; as most FEDs use a completely different toolset and often a completely different OS to the DEVs.

Even with the advances of Sitecore Helix and the use of Gulp scripts for building, there is still a significant gap between the frontend and backend technologies. This also brings up the question of how the FED team access the views to style them, do we load a virtual machine with Sitecore and get them working from there, place the code on a shared development server and allow the FED team to publish to this location? Neither of these solutions is optimal and doesn't answer the question of how to develop in parallel. Enter Sitecore Experience Accelerator (SXA) and the Creative Exchange (CE)¹ toolset.

How it Works
Creative Exchange delivers a workflow and set of tools that allows your DEV team to continue development while the FED team styles, bringing the results together as a cohesive unit. This is achieved by exchanging the base theme assets (images, fonts, styles and scripts) as well as the html output of the site pages into a zip file package, using the Sitecore Experience Accelerator export tools, which can be shared with the FED team. This team can be either internal or external; the beauty of this process is that an external agency can style the pages without requiring access to the source repository.

The following provides a visual representation of the workflow steps for Creative Exchange.

Figure 1. Basic workflow split between FED and DEV teams.

Setting up Your DEV Solution
When first setting up your Visual Studio solution, an additional folder is created under the solution root with a naming standard that will make it instantly recognisable, the suggestion is to name this folder /Static as this is where the static site will be exported to. Although not strictly necessary for the Creative Exchange workflow it allows for your Sitecore asset items to be tracked via the source control system using your preferred sync tool (TDS/Unicorn). From there, your DEVs will set up a page for the Styleguide (often just named Styleguide) within an SXA tenant, that will contain finished renderings and rendering variants that the FED team will use to style; it will be this tree that is exported for the FEDs to work on.

Getting Started
SXA comes installed with a number of industry standard grid systems² to use as the basic layout for your pages. When creating a site (tenant) under the root, the wizard will prompt you for the grid system to use, this comes from the base themes and options such as Bootstrap and Grid 960 are available. For most responsive websites the bootstrap "mobile first" grid system will be more than sufficient and allows your FEDs to work with a framework that they know.

Once the DEVs have set up the site (tenant) and have created a Styleguide root page, a number of the core Sitecore SXA items³ for the site will be added to and exchanged with the FED team, at a minimum this should consist of:

• Partial designs for the header and footer
• Navigation items
• Layout pages for the home and content pages

The DEVs will now start laying out pages under the /Styleguide item within the SXA tenant using the new pages designs. At this juncture parallel development can begin by exporting the site, starting at the Styleguide root, to allow the FED team to begin styling the core items such as the home page banner, navigation, header and footer.

Exporting the Site
Using the SXA supplied tools and starting from the /Styleguide root item the site and assets can be exported⁴ to either a location within your folder structure, or, into a zip file. It is recommended that the site first be exported to your /Static folder so that serialisation projects can be created, then to a zip file using the "Agency drop" mode. This process will export your pages as static html, the css files and images etc from the base them that are required for your site. When exporting it is best to use a naming standard so that the development stage is easily recognisable, something like [YourSite]_v1-0.zips, subsequent exports will increment this version number as required. Once complete the zip file can be made available to the FEDs, either from a shared drop location on the network, or as source from within your source control.

Setting up for FEDs

The FEDs can now pick up the static site assets and begin the task of styling the site components while the DEVs continue putting together renderings and rendering variants. Using the node.js supplied packaging tools the FEDs set up their environment using industry standard toolsets⁵, this will contain at minimum:

• Gulp javascript task processor⁶
• Sass or Less css source language⁷
• Typescript javascript source tool⁸
• BrowseSync http server⁹
• Git client¹⁰

The FEDs will extract the zipped content, or clone the git repository to their working directory and using the standard node.js packaging manager, set up their environment to serve the static pages from the folder as well as gulp tasks to watch and compile the SaSS and/or typescript files¹⁰. To track the version of the stylesheets the sass file(s) should contain at least one header that inserts comments into the completed css file that contain both the build date and the version number. This version number will be referred to by the DEV team when importing the assets back into the Sitecore instance and makes tracking of the development stream easier by allowing a point of reference for both teams i.e. we are using site.css v14.1 and need 'X' modified.

Exchanging the FED Styling
To ensure a smooth transition between FED and DEVs the source files, both SaSS and Typescript should be kept in a directory outside of the web root e.g. In a /src directory underneath the solution root and only the compiled assets added to the content package. As part of the FED build process the source files should be compiled and minified into build files. The grunt build steps should be configured to watch the SaSS and typescript files, compiling them into site.css and site.js respectively and copied to the BrowserSync web root directory. During the development phase a /Debug flag can be applied to the build, skipping the minification step thus allowing the FEDs to debug their javascript as required. As the various components are completed the FEDs they then check in their source files (sass and typescript) to the repository and zip up the folder, starting at the root, for the back end development team, this zip file will be dropped on to the shared location, along with the source files checked in to the repository and the back end team notified that a new build is ready for import.

Importing the Updated Assets
When a new version of the site styling is available the DEVs will import the updated package into Sitecore using the supplied Creative Exchange tools. This will create any Media items that have been added to the assets folders and create any style items that are required for the site. The updated site.css and site.js files should then be synchronised with the TDS/Unicorn packages thus being made available for the staging deployment as it becomes necessary. The site will then be published so that the new assets and styles can be viewed against the development Sitecore site.

---

Works Cited

1. Sitecore. Working with Creative Exchange. [Online] [Cited: 04 06 2017.] https://doc.sitecore.net/sitecore_experience_accelerator/.
2. The grid layout. [Online] [Cited: 04 06 2017.] https://doc.sitecore.net/sitecore_experience_accelerator/.
3. SXA Page Designs. [Online] [Cited: 04 06 2017.] https://doc.sitecore.net/sitecore_experience_accelerator/.
4. Exporting the site. [Online] [Cited: 04 06 2017.] https://doc.sitecore.net/sitecore_experience_accelerator/.
5. BrowserSync. Front end development tools. [Online] [Cited: 04 06 2017.] https://browsersync.io/docs/gulp.
6. Gulp. [Online] [Cited: 04 06 2017.] http://gulpjs.com.
7. SaSS. [Online] [Cited: 04 06 2017.] http://sass-lang.com.
8. Typescript. [Online] [Cited: 04 06 2017.] https://www.typescriptlang.org.
9. Browsersync. [Online] [Cited: 04 06 2017.] https://www.browsersync.io.
10. Gulp environment configuration. [Online] [Cited: 04 06 2017.] http://azemoh.com/2016/05/05/speed-up-your-workflow-with-gulp/.