HackerNoon.com
Published in

HackerNoon.com

Yubl’s road to Serverless — Part 2, Testing and CI/CD

The Road So Far

Testing

  1. Acceptance — does the whole system work?
  2. Integration — does our code work against code we can’t change?
  3. Unit — do our objects do the right thing, are they easy to work with?

Favour Acceptance and Integration Tests

No Mocks

Integration Tests

  • avoid hard-coded IDs, they often cause unintentional coupling between tests
  • always clean up artefacts at the end of each test

Acceptance Tests

Avoid Brittle Tests

  1. create new user
  2. wait 3 seconds
  3. validate user is searchable
  1. create new user
  2. validate user is searchable with retries

Sharing test cases for Integration and Acceptance Testing

  • invoke the function code directly with a stubbed context object, or
  • perform a HTTP GET request against the deployed API

Continuous Integration + Continuous Delivery

  • functions that form the endpoints of an API are grouped in a project
  • background processing functions for a feature are grouped in a project
  • each project has its own repo
  • functions in a project are tested and deployed together
  • achieve high cohesion for related functions
  • improve code sharing where it makes sense (endpoints of an API are likely to share some logic since they operate within the same domain)
  • it’s simple, and all related functions (in a project) have the same version no.
  • it’s difficult to detect if a change to shared code will impact which functions
  • deployment is fast, it makes little difference speed-wise whether we’re deploy one function or five functions

Deployment Automation

  • run unit/integration/acceptance tests
  • deploy your code

Continuous Delivery

  • it gives QA team opportunity to do thorough tests using actual client apps
  • it gives the management team a sense of control over what is being released and when (I’m not saying if this is a good or bad thing, but merely what we wanted)
  • production
  • non-prod, which has 4 environments — dev, test, staging, demo

Conclusions

  • a canary stage for API Gateway and associated Lambda function
  • deploy production builds to the canary stage first
  • use weighted routing in Route53 to direct X% traffic to the canary stage
  • monitor metrics, and when you’re happy with the canary build, promote it to production

Links

  • authentication & authorization with API Gateway & Cognito
  • testing & running functions locally
  • CI/CD
  • log aggregation
  • monitoring best practices
  • distributed tracing with X-Ray
  • tracking correlation IDs
  • performance & cost optimization
  • error handling
  • config management
  • canary deployment
  • VPC
  • security
  • leading practices for Lambda, Kinesis, and API Gateway

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Yan Cui

AWS Serverless Hero. Helping companies go faster for less with serverless.