EVOLVE'13 | Customer Success Story | TWC | Catherine Reusswig

664 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
664
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • ----- Meeting Notes (8/22/13 16:00) -----Develop at the smallest levelBreak a component down to its smallest logical parts. Favor composition over inheritanceIf you want a list-image component for example, don’t take a list component, copy it, and hack it to have an image. A reasonable approach is to create a new component and add the necessary components to it. When you upgrade CQ to a new version, you’ll have no changes to make – it’ll automatically use the new version. (From Antony Hutchinson)Reuse dialogs in composite componentsIf a new component is necessary because it is not possible/feasible/best to stack a bunch of components on top of each other for UI reasons, reuse the dialog from the simpler component to ensure a consistent editing experience across all like components.Develop at the smallest levelBreak a component down to its smallest logical parts. For example, if a component has a call to action button, text area, headline and a background image, it will often make the most sense to develop each of these components individually and assemble them under an composite component. This a.) keeps dialogs small; and b.) ensures maximum reusability.Favor composition over inheritanceIf you want a list-image component for example, don’t take a list component, copy it, and hack it to have an image. A reasonable approach is to create a new component and add the necessary components to it. When you upgrade CQ to a new version, you’ll have no changes to make – it’ll automatically use the new version. (From Antony Hutchinson)Reuse dialogs in composite componentsIf a new component is necessary because it is not possible/feasible/best to stack a bunch of components on top of each other for UI reasons, reuse the dialog from the simpler component to ensure a consistent editing experience across all like components.Overlay to extend the functionality of out-of-the-box componentsAvoid modifying anything under /libs. Avoid copying anything from /libs to /apps. Extend the functionality of out-of-the-box components by overlaying them.Remove Style Specific Class Names from Component JSPsAvoid using style specific class names (like "blue") in the component JSPs which prevents the components from being used in different places and on different sites. Wherever possible, these kinds of class names need to change to reflect the structure of the component (like "label") not how it should be styled.
  • EVOLVE'13 | Customer Success Story | TWC | Catherine Reusswig

    1. 1. Success Story: TWC Presented by: Cat Reusswig
    2. 2. 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
    3. 3. 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
    4. 4. 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 Design 4 DEV Residential Marketing Commercial Marketing
    5. 5. 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/laptop tablet smartphone
    6. 6. Our Agile Process 6 Test driven development Continuous integration Code coverage as part of build • 6 scrum teams • 3-4 work streams • Horizontal team of cross- functional resources • 1 code base
    7. 7. Tools/technologies we use: 7
    8. 8. Evolution of our Build & Deploy process PAST:  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 8
    9. 9. 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.
    10. 10. 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
    11. 11. 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
    12. 12. Q&A  Anything else you’d like to know? 12

    ×