EUHUB Workstream workflow

Overview 

 

1. DEV streams overview
2. Re-platform types
3. Clean start
4. CORE & frontend templates
5. Data migrations
6. Ensighten & Ad Tech
7. Tools and Services
8. New JIRA workflow 

 

Stream breakdown 

Working to 2 week sprint each stream will include a Tech Lead that will manage the team and development for that stream. The leads/devs are not locked into these stream and can change from sprint to sprint and will be reviewed at the end of the sprint.

 

SPRINT 1

Re-platform types 

When we move our brands to MediaOS/InterUnity throughout the EU, we are dividing these into 2 types which is based on the size of the brands content and site traffic.

 

Clean Start Setup (low content & traffic)

• Setup of the MediaOS platform on staging/production instances with the US theme if it is a global brand. For non-global brands, the theme will be based on the latest Cosmo US theme.

 

Clean Start + Data Migration (large content & site traffic)

• Setup of the MediaOS platform on staging/production instances with the US theme if it is a global brand.
• Data migration using the Quack migration toolset

 

 

 

 

Clean start setup 

Every brand that is moved over to MediaOS/InterUnity will go through a clean start which involves the setting up of stage/prod instances by Dev Ops and the setup of the brands theme by DEV with the below checklist.

 

Environments

1. Setup Dev boxes using HDM/HMI.IO environments (Setup by DEV)
2. Setup Stage and Prod (Dev Ops)
3. Setup Fastly/Memcached layers (Dev Ops)
4. S3 bucket for stage/prod environments (Dev Ops)
5. Initial content setup for editorial (DEV)

 

Setup RAMS-ID

1. Site and tag setup 
2. Create User accounts for DEV/Editorial

 

 

 

 

Clean start setup 

Every brand that is moved over to MediaOS/InterUnity will go through a clean start which involves the setting up of stage/prod instances by Dev Ops and the setup of the brands theme with the below checklist.

 

Create/setup Region theme

1. If it is a global brand, the theme is copied over from themes-us
2. For local brands, the Cosmo US theme is used and refined in the CORE/Front-end templates stream
3. Add S3 bucket settings to filter config file 
4. Clean-up theme paramters to match the settings of the brand
5. Add social links for top nav
6. FB App Id and Secret
7. Video 

 

 

 

Clean start setup 

Every brand that is moved over to MediaOS/InterUnity will go through a clean start which involves the setting up of stage/prod instances by Dev Ops and the setup of the brands theme with the below checklist.

 

Setup/configure Content

1. Branded Header
2. Content Type
3. Section
4. Subsection
5. Ad Categories
6. T&C
7. Footer and Logo
8. Sandbox nav
9. Hamburger nav
10. Ad Placement file
11. Content Metadata file
12. 404 page (if needed)

 

 

 

CORE & Frontend Templates 

Spread over CORE feature and front-end template development this stream includes feature sets that extended the CORE and are available to all MediaOS sites with the latest version of the CORE.

 

This is divided into 2 codebases:

1. RAMS-CS/sites (backend functionality for the CMS)
2. Themes-base (front-end core feature such as html/php components/blocks and JS/SASS templates)

 

Examples:

• DS mega-menu
• DS Alternate home page
• Menu Builder

 

 

 

 

 

What is CORE? 

Working closely with HDM/HMI, this stream involves the development of front-end/CMS functionality that improves the editorial workflow in the CMS and creates a more intuitive/engaging UX on the front-end.

 

Process

1. Feature is signed off by HDM/HMI after a business case is presented 
2. Create POC of the feature
3. Create PR (Pull request) and assign to HMI team for peer code review
4. After if has passed code review it is passed over to QA to test the new functionality against the latest CORE in the front/back-end
5. When it has passed QA, it is then passed over to HDM for their code review/QA
6.  After HDM has signed off it is then packaged with the latest CORE from the schedule in the release hub - http://releasehub.hdmtech.net

 

 

 

 

 

What is Front-end Templates? 

Oftern linked directly with CORE development for CMS functionality, front-end template development can include:

• Typography and styling
• ​JS functionality applied to the front-end and CMS 
• Bug fixing of JS conflicts and responsive issues

 

Process

1. Design assets are created by Design/UX prior to the sprint and added to tickets
2. If it is not a local brand, the US equivalent theme will be copied over from themes-uk
3. Development includes the setup typography, colour schemes and custom JS functionality
4. Once FE tickets have passed peer code review, they will passed over for QA
5. After passing QA, it is then passed over to Design/UX with bugHerd

 

 

 

Data migration 

Using the Quack migration library and toolset, migrations can be done using variety of sources to map content from EZ Publish, Expression Engine and Wordpress:

 

https://github.com/HearstUK/migrations​

 

Sources:

• site scraping
• Data base
• XML
• Json

 

 

 

 

 

Whats in a data migration? 

Process

1. Gap analysis between existing platform and mediaOS is reviewed & tickets are created
2. Content mapping is created for each brand using the Quack library and is tested on HDM/HMI dev boxes
3. Once the initial mapping is working on a dev box, it is passed over to QA for  quick sweep, which we are working towards making this automated
4. After the first round of QA, the content mapping will then be applied to the AWS Lamba stack to process all of the data from that content type
5. The complete migrated data is then saved out as a database back and uploaded to QA dev boxes for further testing

 

 

 

Ensighten & Ad Tech 

The global Unity Ad layer and 3rd party services are delivered via ensighten such as Comscore, GA, Lotame, Chartbeat, etc. The Ad layer is current owned/managed by Weyland Jung at Hearst CORP and will not require any development by DEV with the exception of setting up the Ad placements in the MediaOS theme.

 

For more info on the ensighten deployments, naming conventions and process please check out: http://docs.hdigital.net/ensighten.html

 

 

 

 

 

The ensighten process...

1. Ticket is created in this stream and taken by DEV and new deployment code is created as a git feature branch in the ensighten repo with the ticket number
2. After the initial code has been added to the feature branch, a pull request is created and assigned to another team member
3. Deployment is created in Ensighten from the repo with the JIRA ticket message for the edit message for clearer version control in the event published changes need to be rolled back
4. QA/UAT test deployment on DEV/QA boxes using chrome/firefox plugin tools.
5. Once the deployment has passed QA/UAT, it is published to the DEV Ensighten space
6. Pull request is created for the Hearst Corp ensighten repo to do code reviews by HCORP/HDM/HMI/HMUK
7. When the pull request has been merged, the deployment will then be merged/published to the ensighten PROD space.

 

 

 

Tools & Services

With MediaOS and as we move to a micro-service API driven model with InterUnity we will be developing tools/services to extend the CORE functionality and streamline workflow for DEV/Editorial

 

Current library of tools/services:

• Quack migration toolset/library
• Node.js bulk redirect tool for migration testing
• HIVE people management platform
• Apple News
• Facebook Instant articles

New JIRA workflow

To create more visibility and streamline the DEV stream model we are moving towards a global board that uses EPICs for brands with filtering of streams with components/labels/fix versions

 

http://bit.ly/1RojXt5

 

 

Ticket structure

Example of a ticket for HBZ UK for the migration stream: https://thetower.atlassian.net/browse/HMIWS-6

 

Fix version: - Brand label

Component: - type of stream

Epic Link: - Brand Filter