Success Story: TWC

Presented by: Cat Reusswig

Agenda Why TWC chose Adobe CQ

What we accomplished in our Phase 1 Delivery

What we are doing with Responsive Design in our current new web deliveries

What our configuration looks like

Our agile process

Tools/technologies we use

Evolution of our Build/Deploy Model

How we test

Our support model

Wrapping up w CQ Anecdotes – things we love/hate about CQ

Q&A 2

Why TWC Chose CQ5: Most transparent COTS application suite Alignment with CTG Web Services technology stack: Superior Development platform and Editorial

capabilities Backing of Adobe

3

Phase 1 Delivery – what we accomplished:

Migration of ~60 domains to one: timewarnercable.com for both our residential and commercial customers

Geo-targeting of content and pricing on a regional basis

Site redesign

New team

New platform

New processes

Awarded by cableFAX's "Best of Web Awards”

Best Cable Site

Best Overall Web Site Design4

DEV ResidentialMarketing

CommercialMarketing

Our Current Focus: RESPONSIVE

5.5.2 version of CQ5 so rolling our own

Establishing new team standards to ensure reusable components

Interweaving responsive with not-yet-responsive to enable time to market speed changes on the website Challenging with CQ to accomplish

what is in essence yet another migration from CQ to CQ

Creating new portion of the site for our online ordering = new migration with complex integrations

5

Desktop/laptoptablet

smartphone

Our Agile Process

6

2 week sprint cycles

Scrum methodology

Test driven developmentContinuous integrationCode coverage as part of build

Collaborative story creation between Marketing & Development

• 6 scrum teams• 3-4 work streams• Horizontal team of

cross-functional resources

• 1 code base

Tools/technologies we use:

7

8

Evolution of our Build & Deploy processPAST:

Tools: Maven, curl commands, Jenkins, shell scripts, CQ replication

Overview: Used CQ MVN plug-ins to build, Curl to deploy with replication queues

Problem: New deploy = New code artifact, Minimum to no testing. Not much control of which instance is getting Updates. Still manual steps. Stale code remains in CQ after refactors

PRESENT:

Tools: Gradle,GitHubEnterprise, Selenium, Artifactory, Shell scripts,Groovy, JIRA, Jenkins, Confluence

Overview: Gradle handles both code build, package creation and deployment to individual instances

Each Build as a tag in Github and its related artifacts stored in Artifactory

During Each Deploy, all existing code and related configuration are removed

During a build, 700+ Unit, Functional, Integration tests run prior to leaving CI/DEV. No code is promoted to Release branch without all core tests passing

Once artifact is deemed a Release Candidate, a deployer can choose which build is required as well as which environment with a click of a button

Problem: Need to increase code coverage, deploy instances is done one at a time

FUTURE:

Move to batch (A/B) deployments for publishers

Continue to improve All test to increase coverage and complete automation

Jenkins workflow: continuous integration

9

Testing Additional Notes: We use VirtualBox on developer workstations to interact with various Windows OS/browsers We have additional UI Integration and Regression test that can be run locally or in QA Plus performance tests via the Selenium Grid We have a variety of additional devices from tablets to smart phones.

Our Support Model No traditional Operational, CM, QA or Test teams!

Each scrum team has a Senior level QA engineer, who also is responsible for UAT hand-off & delivery

For non-JAVA Development work, a cross functional team of Analytics, DevOps, Infrastructure and UX engineers assist each scrum team

Environment & Application Support Hardware, Storage, Hypervisor support is provided by an

integrated infrastructure team that extends to DevOps

All monitoring and Tier 1&2 Support is handled by 3Share Rom Services.

Higher Support Tiers are a collection of Developers, DevOps, QA and 3Share Services with an all for one, one for all mind set

10

CQ Anecdotes from the team to wrap up!Love

Ability to create custom tools for marketing team to manage their own content +WYSIWYG authoring interface

Ability for dev to customize/integrate almost everything including 3rd party (non-adobe) products

REST principles

Selectors in URLs

Built on Open Source tools/libs

Apache/Dispatcher/caching on the front end for scaling load

Teasers/async load of content can aid in cache ability yet maintain personalization.

Looking at the code, including the various adobe widgets in the repo – amazing the things you find.

CQ5 is a CMS on Steroids!  It truly is an enterprise CMS in a class all it's own.  

That everything, I mean everything is accessible via API, JMX, SLING, etc. This is freaking awesome!

Hate Documentation

Training doesn't follow best practices

Over-sold integration of products in 5.5

Clientlibs – look at all the extra requests for extra little snippets/"depends on", especially for teasers, user profiles, analytics, etc.  

Double-loading jQuery in order to have current version

The incomplete thinking around designs and styles

Lack of depth in resource knowledge due to being an acquired software model

The documentation (ooh did we say that already before??!!??)

11

Q&A

Anything else you’d like to know?

12