Tech surge - Lloyds
(spring 2017 - Winter 2017)
Context
- Existing Lloyds teams have no ownership of their tools or environments
- Their CI is centralised and very siloed
- Lot's of engineers and other teammates are placed by vendors,
- Poor ownership of product
- Dev environments are very hostile and locked, testing is very fastidious
- The work culture and technologies are behind current time and market
- However some key members of the current management are very aware of these issues and willing to fix them
Role
- Development environment revamp to reach actual continuous integration
- Allow more automation
- Give engineers back control over their tooling
- Isolate build environments from locked CI ones
- Promote and bring technologies with existing teams for early adoption (with loads of help and guidance from@tim.webster)
- Promote cross knowledge sharing across the scope of stakeholders
- Bring the possibilities to run nearly full stack environment during development
- Build new CI pipelines as codes using containerised environments
Outcome (sept `17)
- some projects are starting using the new developed CI stack
- other teams are knocking to be involved in the process too
- the ability to build and ship very quickly has been proved
- dev environments are unlocked giving the choice of scm to teams (e.g. gogs or gitlab, vs gerrit previously)
- several people of the existing teams can now create and handle their own CI
- the critical point of no return has been reached were the change is completely owned by the client
Tech stack
linux, jenkins, nginx, docker, rancher,
webpack, nodejs, gulp,
sass, react, redux,
es6, jest, selenium, cucumberjs,
Re-platforming java/jsp to nodeJS
(fall 2013 - spring 2015)
Context
- tech stack (apache, jsp, java, mysql, maven, svn) was too big, not modularized,
- web application was not FED-friendly and had performance issues
- rollouts were very difficult (nearly 1/month)
- the tech stack and process were far from any CD/devops mindset
- tools and processes were not compliant with agile teams
- new CTO convinced top-management on necessity to re-build technical stack from scratch
Role
- setup a team to implement a new web stack that would be based on a data platform
- picked up developers to build a team (@cormacflynn, @fabienjacq - a devops FED, @thaume)
- especially worked on asynchronous data aggregation, bringing Promises-based and resiliency skill to the teams (pre-graphQL era)
- invested a lot of time evangelising about TDD as well as setup the test framework
- managed community around new stack, providing support, cross-team sync, weekly reports and pivoting
Outcome (sept `15)
- nodejs application (named Limbo)
- serving more than 300 req/s/process
- continuous delivery (several times a day)
- CI
- unit tests (more than 85% coverage today)
- functional tests
- current web rendering stack at Viadeo, I'd be very proud to talk about ;)
Tech stack
git, git hooks, nodejs, grunt, brunch.io,
sass, handlebars, react, d3,
Promises, expressJS, LocomotiveJS, bluebird, ramda,
es6, coffee, mocha, chai, selenium, cucumberjs,
linux, jenkins, handlebars, nginx, docker,
nodejs workers monitoring, kibana, graphite, finetuning
Tetra-js - Home-backed JS library
(spring 2012 - spring 2014)
Context
- building more and more client-side applications
- front-end developers not yet all JS proficient (~15 team people)
- product made in a fire-and-forget mode so UIs had to be build for a long time
- not so much client-side MVC frameworks, and (backbone was still young)
- existing scripts tight-coupled with unmaintained prototype lib
Role
- hired a dedicated dev to build a framework (@olivierhory)
- build our own JS framework named tetra-js, using devs feed-back for each steps
- open-sourced it to put focus on quality (and it worked)
- trained and evangelized dev and newcomers
- also have been given the chance to hire a dedicated dev to introduce testing in our front-end apps (@cormacflynn - the most talented dev I've ever known)
Outcome (sept `15)
- this tool gave a lot of consistence across projects code for more than two years
- front-end devs took lots of experience using TDD - seems obvious now, but when I started, it was completely out of scope
- even though very useful, decision to depreacate it was made when we switched to a new codebase
- lack of resources to maintain such a framework
- not enough hire-friendly (backbone or angular, were better skills to write on a résumé)
- the rise of new frameworks like react and angular proved to be more suited
Tech stack
git, grunt, javascript, jasmine, mocha