Thoughtful React.js Development & Automation

About

Evgeniy Maslovskiy (@Spleshka)

  • CTO @ SystemSeed
  • Active open source contributor

Presentation plan

  • Long term projects mantra

  • Local dev automation

  • Code quality

  • Automated Testing

  • Continuous Integration

  • Continuous Deployment

  • Development tips & tricks

Team's background

  • Originally backend (PHP) based dev team

  • Shifted to Decoupled / Frontend 3 years ago

  • Work with enterprise clients

  • Deal with long term projects

Long Term Projects

Long Term Projects Mantra

  • Simplicity is the Holy Graal

  • Every routine not related to the project dev must be automated

  • Set up quality metrics in the beginning of the project

  • Any monkey should be able to deploy

Local Dev Automation

Docker

  • The most obvious & most flexible local dev choice

  • Problems: devs need to learn Docker

  • Problems: real life is different from Hello World samples

  • Problems: too long commands / arguments

Makefiles

  • Old School Linux tool

  • Ships out of the box in Linux & Mac

  • One file to rule them all

Makefiles. File example

Makefiles. Example of usage

Makefiles. Example

  • One command project installation [make install]

  • One command code checks & fixes [make code:check]

  • One command tests run [make tests:run]
  • One command sync [make sync:db] or [make sync:files]
  • One command yarn [make yarn <args>]

Makefiles. Real life example

  • Open source projects

  • Remove entrance complexity

  • https://github.com/systemseed/drupal_reactjs_boilerplate

Code Quality

Code Quality

  • Set up at the beginning of the project

  • Aim for simple make code:check and make code:fix

  • Make code check in Git pre-commit hook

  • Make code check first step in CI

Automated Testing

Automated Testing

MUST HAVE

Automated Testing

Writing tests is not

harder than writing code

What tests to use for backend?

  • Unit? NO

  • Functional? YES, when it has code & db connection to your app

  • Acceptance (End to end)? In most cases - NO

What tests to use for frontend?

  • Unit? NO

  • Functional? IT DEPENDS

  • Acceptance (End to end)? YES

Any other tests?

API

  • API tends to change quite often
  • Cover at least cases used by frontend

Continuous Integration

Continuous Integration

CircleCI

  • Creates isolated environment for every git push
  • Docker friendly
  • Super flexible & powerful
  • Free*

Continuous Integration. Makefiles

  • Runs the same commands as developers locally

  • Guarantees working commands at all times

  • Makes CI process transparent for the developers

  • Eventually has very positive efficiency boost

Continuous Integration. Testing

  • Runs the same set of tests as locally

  • Functional & API tests are invoked within CI container

  • Acceptance tests must be checked against real hosting env

Continuous Integration

  • First, [make install]

  • Then, [make code:check]

  • After that, [make tests:run api] and [make tests:run functional]

  • Fail fast (3-5 mins)

  • If all good, deploy to the clone of Production environment

  • Finally, [make tests:run acceptance]

Continuous Deployment

Continuous Deployment

  • Every feature is branched from stage branch

  • When feature is accepted, Pull Request gets merged into stage

  • Stage acts as hands-off dev environment

  • At the end of stage CI job, it opens PR to master & merge it

  • Master CI job makes backup & deploys code to Production

Documentation

Documentation

  • For developers
  • For clients
  • Confidence of very good project quality

Documentation for clients

Short video clips

  • Much faster & easier to learn this way
  • As simple to create as taking a call with screensharing
  • If UI has changed, easier to detect the discrepancy
  • Client should be able to contribute to the docs
  • Readme.io

Documentation for devs

  • Documentation is in the codebase. I.e. /docs folder
  • Laziness trick: connect to docs hosting software
  • Build docs automatically to the web accessible URL

We have some documentation

vs

Yes, we have documentations, here's the URL

Development Tips & Tricks

Code comments

WHY it was done

instead of

WHAT was done

Style guide

  • New project. Separate repository
  • Don't think about the data structure
  • Focus only on reusable components
  • No design overwrites in the long run
  • Clients love it. Editors' reference

Style guide

Style guide

Tools

  • final-form (react-final-form) for forms
  • redux-saga for side effects (like backend API calls)
  • next.js for SSR and code / css splitting per page types
  • Define transformers for data normalization

Thank you

Made with Slides.com