Create a gist now

Instantly share code, notes, and snippets.

That Conference - Happy Full-Stack JavaScript Campers - Ryan Niemeyer

Presentation notes/links

Happy Full-Stack JavaScript Campers

A Journey Towards Node and Micro-services

Ryan Niemeyer - @RPNiemeyer

LeanKit's dev journey

Over the last two years, LeanKit has been moving pieces towards Node (http://nodejs.org) on the server-side and React on the front-end (https://facebook.github.io/react/). We are moving towards micro-services that can be deployed independently allowing our teams to work in a decoupled manner.

The Challenge

How can we maintain quality, consistency, and maintainability in this world of micro-services and decoupled teams/projects. People, processes, and tools are what make this possible for us.

People and Processes

Delivery Squads

  • Goal is teams of 7 (+/- 2) people
  • Have skills for 80% of the work
  • Each member only belongs to 1 team
  • Work is assigned to squad not individuals

Guilds / Squads

Teams still communicate within their role (developers across squads are in a "guild" and have training/meetings with each other.

My Squad

  • Team Rocket (other web squad is Team Groot)
  • LeanKit squads are situated in same office space
  • Remote members can be up on Monitors in squad room at anytime
  • Our team has a limited number of formal meetings, but are in constant communication
  • We make liberal use of Zoom (http://zoom.us) for video sharing/conferencing

Kanban

  • We use our own tool as part of building LeanKit
  • I use it personally as well (for example, I had a board to work on this talk)
  • WIP Limits (WIP = Work in progress). Limit how many things are in progress to focus on flowing things through the system.
  • FSGD (Frequent, Small, Good, Decoupled) (http://leankit.com/FSGD)

Pairing

  • Our team pairs about 90% of the time
  • Seeing tremendous benefits from pairing
  • Quality - combine knowledge and experience of both people
  • Learning - experienced person can teach other person
  • Context - more than one person understands piece of development, trade-offs, and functionality
  • Social - build strong relationships

Code Review

  • Review all code going into repositories
  • Never merge our own code
  • Merge from fork to upstream feature branch. QA tests from feature branch before code is integrated back into repository.

Tools - Ops

  • Drone (http://drone.io) - continuous integration server
  • Docker (http://docker.com) - deploy functionality in containers
  • Docker hub (https://hub.docker.com/) - drone builds push container images up to private docker hub to be deployed further
  • Dependencies are only installed once as part of drone build, then become part of image that is deployed further
  • Rancher (http://rancher.com) - Platform for managing containers

Tools - Dev

Testing

Styleguide / Linting

Why Styleguide?

  • Creatures of habit
  • No "turf wars"
  • Easier for new devs
  • Focus on what matters
JSCS (http://jscs.info)
  • Comprehensive style rules
  • Includes ability to fix code
  • JSCS is now deprecated
  • JSCS has merged with ESLint
ESLint (http://eslint.org)
ESLint / JSCS Benefits
  • Let tools do their job
  • Spend more time on solving the actual problems
  • Consistent / predictable code
  • Less stress/conflict/time reviewing/fixing these type of issues

Build Scripts / Tools

Conclusion

Challenges

  • Where to slice our services?
  • Decoupled, but how to still share wisdom?
  • How to keep all projects up-to-date?
  • Always more automation possible

Successes

  • Delivering value faster
  • Strong confidence in our code
  • Automation opens up dev options
  • Enjoyment and satisfaction working in our stack

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment