Your team has wrapped up the requirements and analysis phase of a new project. The UX team is finishing up their work and you finally have a glimpse of how the information on the site is going to be presented, what widgets you need, what content goes where, and you’ve started to build your strategy around how you will begin to implement this in Ektron.
As you go through each page of the UX and IA documents, you begin identifying the content types required, how menus will be structured, what will be a smart form, what will be custom code, what will require a template, etc. Eventually, you’ll have a pretty robust implementation guide that you can work from. All set to start implementing right? Not quite. Careful consideration needs to paid to your development environments and how custom code, configuration, and content will be published to the different environments. Ektron has a great tool that makes this much more manageable. This tool is called eSync.
Let’s review a somewhat typical development and deployment configuration.
A development server – This is the most unstable of the environments. Developers may have local copies of the application and develop locally, but will actively be deploying changes to this environment to test their changes and configuration in a non-local environment. Changes will be code and configuration based and the change frequency will by many times per day.
A staging server – This server is generally very stable. The code and configuration change frequency on this server will most likely be weekly. Acceptance testing will occur here and for now, let’s assume that all content that will be moved to production will be entered on staging first.
A production server – This is the server that will have the final code, configuration, and content that will be available to public when the site goes live.
The challenge here is moving content and configuration between environments accurately and efficiently. Content will typically flow from the production server down to the development server, whereas configuration will flow from the development server to the production server. It’s challenging for a few reasons. One reason is that for developers and configurators, it’s much less efficient to have to reconfigure each server as development proceeds or as you want to release new features. It’s also not a guarantee that it will be configured the same way in each environment if it’s done manually.
The second reason is that the better the content is in the development environment, the easier it will be to write code and configuration that will work when deployed to staging and production. Quality content will lead to improved code and configuration quality. Also, if your site has content that’s entered from the community, like ratings or comments, moving all that data from production to your staging/development environments wouldn’t be very feasible. This is where eSync steps in.
eSync is a tool that is used to move and synchronize content, configuration, and even code files from one server to the other. It works bi-directionally so if you have a connection between your production, staging, and dev servers, you can move content, configuration, and your files to and from each server seamlessly. eSync also performs data conflict resolution which gives you control of the data if there is a conflict, and has a feature that allows you to choose specific changes you would like to promote to another server, but it can do a full synchronization. Another great feature is scheduled synchronizations. If you have a website that has a lot of content from the community, scheduling a sync down to your staging environment periodically is possible.
eSync is definitely an extremely valuable tool for managing Ektron deployments.