python - code quality and production monitoring

Post on 29-Nov-2014

278 Views

Category:

Engineering

3 Downloads

Preview:

Click to see full reader

DESCRIPTION

About code quality & production monitoring

TRANSCRIPT

Code Quality to Monitoring production: use cases and best practices

David Melamed

Pyweb meetup - September 21, 2014

Agenda

What is good code?

How to measure quality code?

Continuous Integration

How to efficiently monitor production?

About me

Full-stack developer at Cloudlock

Fond of technology & automation

Code Quality Evangelist

Geek on my free time

About CloudlockFounded: 2011

Headquarters: Waltham, Mass. (U.S.)

R&D Headquarters: Tel Aviv

Employees: 80+

Funding: $28M+

700+ Customers 9,600 Unique Apps Discovered

5 million Users under Management

13 billion objects processed daily

Native Cloud Security Solutionsfor SaaS Applications

Selected customersInvestors

What is good code?

Good code is…

Easy to read & understand

Easy to extend

Easy to maintain

Testable

How to write good code?

from xkcd

Good code requires constant

REFACTORING

The Code Quality Star

Coding Standards

Code Review

Automated Tests

CodeComplexity

ArchitectureDesign

Source

Code should be easy to read

Code should be readable

Avoid comments but avoid obvious ones (the code should be self-explanatory)

Avoid comments too verbose

Comments need to be maintained

Coding Standards

The Zen of Python (PEP20)

Beautiful is better than ugly

Explicit is better than implicit

Simple is better than complex

Complex is better than complicated

Readability counts

Coding Style: Readability Counts

“Programs must be written for people to read, and only incidentally for machines to execute.”

Abelson & Sussman, Structure and Interpretation of Computer Programs

PEP8: Style guide for PythonIndentation

Maximum line length

Blank lines

Redundant white spaces

Imports

Comments

Naming conventions

How to check /enforce PEP8

Pycharm (Tools > Flake8)

Git pre-commit hook (http://goo.gl/bteYkq)

Jenkins job for continuous integration

Naming is key

Naming best practises

Adopt a convention and stick with it (fetch vs. retrieve vs. get)

Use intention-revealing names

Avoid misleading readers

Make meaningful distinctions

Use searchable names

Avoid mental mapping

Use domain names

From Clean code, R. Martin

Code Architecture

Best Practices in Code Architecture

OOP

DRY

SOLID

Loose Coupling

Don’t Repeat Yourself (aka DRY)

http://www.sonarqube.org/manage-duplicated-code-with-sonar/

SOLID principles

• SRP: Single Responsibility Principle

• OCP: Open/closed principle

• LSP: Liskov substitution principle

• ISP: Interface segregation principle

• DIP: dependency inversion principle

http://www.codeproject.com/Articles/93369/How-I-explained-OOD-to-my-wife

http://www.codeproject.com/Articles/93369/How-I-explained-OOD-to-my-wife

http://www.codeproject.com/Articles/93369/How-I-explained-OOD-to-my-wife

http://www.codeproject.com/Articles/93369/How-I-explained-OOD-to-my-wife

http://www.codeproject.com/Articles/93369/How-I-explained-OOD-to-my-wife

Loosely Coupled Components

Main principlesSplit components into repositories

Web app: use clean layers

view / endpoint (presentation)

service (business logic)

DAO (model)

Use message bus for communication inter-components (i.e. RabbitMQ)

Use daemons / workers for long-running tasks

Use events / signals to decouple unrelated actions

Microservices

Architecture at Cloudlock

Nginx

AWS VPC

Message Bus (RabbitMQ)

Web Server

API Server

RDS PostgreSQL

ElastiCache Redis

Authentication Gateway

Worker Worker Worker

Logs

Code Reviews

Tools for code review

Github Pull Requests

Review Board

Gerrit

Crucible

Code documentation

Code Testing

Different types of testsManual Test

Unit Test

Integration Test

System Test

Acceptance/Regression Test (end-to-end)

Smoke Test

Unit Test

Test if small, distinct and isolated portions of code are working as expected, provided some input

Mock your dependencies (database, logger, service)

Should be very fast

No need to test EVERYTHING (i.e. private methods)

Frameworks: unittest, pytest and nose

PytestNo need for base class (works both for classes and methods)

More pythonic than unittest

Fixtures (conftest.py)

Parametrized tests

Markers

Various plugins for coverage, bdd, django, twisted…

Used for unit tests, integration tests and end to end tests

Integration TestsTest communication between services

You may mock some of the dependencies depending on what you test

System TestsGlobal test, more functional of the whole system

TestApp (Pyramid app) using a test database

Call the API and test the expected response code

End-to-end testsSplinter: web driver abstraction (firefox, selenium)

splinter-pytest: fixtures for browser

Plugin for rerun flaky tests, tests with steps

Use Selenium Grid to test several browsers

Smoke TestsMake sure the system is alive

Tests that the components are working

Tests that the components can communicate

Health check / status page

Measuring code quality

Code Quality Metrics

Code Standards Violations (pylint /flake8/pyflakes)

LOC (Lines Of Code)

Cyclomatic Complexity

Unit Tests Coverage

Code Coverage

Makes sense only for unit tests

Calculates the coverage based on the paths run by the tests

100% coverage is not a goal on its own

May be misleading regarding the code quality

Unit Test Diff Coverage

Mutation Analysis

From Mutation analysis vs. code coverage in automated assessment of students’ Testing Skills (P. Ihantola)

PylintReport ====== 85 statements analysed. !Duplication ----------- !+-------------------------+------+---------+-----------+ | |now |previous |difference | +=========================+======+=========+===========+ |nb duplicated lines |0 |0 |= | +-------------------------+------+---------+-----------+ |percent duplicated lines |0.000 |0.000 |= | +-------------------------+------+---------+-----------+ !!!Messages by category -------------------- !+-----------+-------+---------+-----------+ |type |number |previous |difference | +===========+=======+=========+===========+ |convention |18 |18 |= | +-----------+-------+---------+-----------+ |refactor |2 |2 |= | +-----------+-------+---------+-----------+ |warning |1 |1 |= | +-----------+-------+---------+-----------+ |error |4 |4 |= | +-----------+-------+---------+-----------+ !!!Messages -------- !+-----------------------------+------------+ |message id |occurrences | +=============================+============+ |line-too-long |10 | +-----------------------------+------------+ |no-name-in-module |4 | +-----------------------------+------------+ |missing-docstring |4 | +-----------------------------+------------+

Global evaluation ----------------- Your code has been rated at 5.18/10 (previous run: 5.18/10, +0.00) !Raw metrics ----------- !+----------+-------+------+---------+-----------+ |type |number |% |previous |difference | +==========+=======+======+=========+===========+ |code |90 |63.83 |90 |= | +----------+-------+------+---------+-----------+ |docstring |30 |21.28 |30 |= | +----------+-------+------+---------+-----------+ |comment |5 |3.55 |5 |= | +----------+-------+------+---------+-----------+ |empty |16 |11.35 |16 |= | +----------+-------+------+---------+-----------+ !!!Statistics by type ------------------ !+---------+-------+-----------+-----------+------------+---------+ |type |number |old number |difference |%documented |%badname | +=========+=======+===========+===========+============+=========+ |module |1 |1 |= |0.00 |0.00 | +---------+-------+-----------+-----------+------------+---------+ |class |2 |2 |= |100.00 |0.00 | +---------+-------+-----------+-----------+------------+---------+ |method |1 |1 |= |100.00 |0.00 | +---------+-------+-----------+-----------+------------+---------+ |function |6 |6 |= |50.00 |33.33 | +————+-------+-----------+-----------+------------+---------+ !!!!!!!!!!

Test Automation

Why do you need automated tests?!

Optimise speed, efficiency and quality

Catch the bugs upfront

Safety net for refactoring

On the Road to Continuous Integration

Several “Continuous” processes

Continuous Integration

Continuous Deployment

Continuous Delivery

Several platforms for CI

Jenkins

Travis CI

Circle CI

Shippable

BuildBot

Continuous Integration FlowFeature Branch

Develop Branch

Updates Github PR

Git Push

Several jobs: - pep8 compliance - unit test - integration test - end to end test

Merge PR

Pull Request

Tag

Deployment

Code Review

Jenkins dashboard

Automated Deployment

Pick the right tool to deploy

AWS ElasticBeanstalk

AWS OpsWorks

Chef

Puppet

SaltStack

Ansible

Ansible

http://terry.im/wiki/terry/attachments/29786135/37552129.png

It works only on my machine

The Docker Project

Run everywhere

Run everything

Advantages:

• Pricing

• Speed

• Unifying environments

• Testability / reproducibility

• Easily add/replace components

Docker on your Mac

http://www.warski.org/blog/2014/05/spray-server-docker-container/docker-stack-5/

Production Monitoring

Production MonitoringAWS CloudWatch

End-to-end tests running in Jenkins

StackDriver

Log analysis (streams)

Questions?

Python developers WANTED

Contact: dmelamed@cloudlock.com

top related