DNA Project Base

A common base and set of workflows for creating and managing web-based application platforms

About

The DNA Project Base is our (extremely biased) PHP*+JS-based Project Base that allows rapid generation of deployable, testable and maintainable custom full-stack applications suitable for SaaS projects.

It’s main focus is to enable automation in as many aspects of the development process as viable, so that the developers’ energy is focused on custom business logic (the “DNA”).

Read more below. Developers may want to check out the source code directly: https://github.com/neam/dna-project-base

* Since the architecture is Docker-centric, micro-services within the project can be written in any server-side language. Most extensions and boilerplate for code-reuse however are currently written in PHP, heavily oriented around the Propel 2 ORM, barebones PHP and (at least historically) Yii Framework.

DNA Methodology

Lets software engineers focus on the project-specific business logic – the “DNA”

Code Generation

Use Code Generation to save tons of repetitive work

12-factor

Follows the 12-factor manifesto to ensure scalability and maintainability when deployed

DNA Methodology

What helps when wanting to focus on the core logic?

  • Thin applications, fat dependencies
  • 12-factor
  • Automation
  • Agile data modeling
  • Event-based behaviors
  • Configuration and model re-use
  • MVC
  • Merit-based choice of components
  • Codeception-based testing helper scripts

Code Generation

What does it mean in practice?

  • Generate core application model classes and metadata for use throughout the application
  • Generate a RESTful API
  • Generate AngularJS-based CRUD allowing data display and manipulation in Frontend

Tech Overview

Because visuals are helpful

The Twelve Factors

And how it is taken care of in a DNA Project

I. Codebase

One codebase tracked in revision control, many deploys

DNA Projects uses git and supports commit-specific builds, ensuring that only code that is tracked in version control gets deployed. One project may consist of several 12-factor apps working together in a distributed system, in which case each 12-factor app is deployed individually.

II. Dependencies

Explicitly declare and isolate dependencies

Each 12-factor app’s root composer.json contains the metadata that defines necessary server software and configuration, used by the buildpack to build a full operating system running our app, packaged as a Docker image. Even the operating system of choice (Ubuntu 14.04 LTS) is explicitly declared in the Yii DNA Deployment dependency. For software dependencies, Composer, NPM, Bower, Git submodules and Git subtrees are used as appropriate. At Neam, we believe in thin applications, fat dependencies – thus we try writing reusable packages that we make available open source.

 

 

Links

 

 

 

III. Config

Store config in the environment

Config is handled by environment variables, set either at the operating system level (when deployed) or locally using a .env-file.

 

 

Links

 

 

 

IV. Backing Services

Treat backing services as attached resources

This requires careful handling of schema and data, since if we are to support swapping out the database server, we need to quickly be able to populate it with a working schema and set of data corresponding to either the latest development schema or the latest user generated data. DNA Projects uses highly automated workflows to initiate, upgrade, migrate, backup, copy and version schema and data via the pre-release testing workflows.

Development can be done against a local database server container (included in the stack), deployed to a Docker-based build/staging server for quality assurance and testing, then deployed in production in using highly reliable and scalable infrastructure like Amazon RDS, all without loosing schema changes or user-generated data.

 

Links

 

 

 

 

V. Build, release, run

Strictly separate build and run stages

The build stage is handled by Dockerfiles and the build scripts in Yii DNA Deployment.

The release stage is handled by Docker Cloud, resulting in a Docker stack  deployed in a highly available cluster environment.

The run phase is managed by Docker and Docker Cloud.

X. Dev/prod parity

 

 

Keep development, staging, and production as similar as possible

Local development, staging and production are all based on the same set of Docker images and services. Thanks to this, it is easy to run complex stacks with minimum effort. We maintain docker-compose.yml files for different purposes in docker-stack so that they work seamlessly both locally, in staging and in production.

Links

 

 

 

 

XI. Logs

Treat logs as event streams

Buildpacks should already be configured to write log data unbuffered to stdout. Docker takes care of the rest. Locally, we tail the output from running Docker containers, and for staging and production environments we use papertrailapp for remote log handling.

 

 

Links

 

 

 

 

 

 

VI. Processes, VII. Port binding, VIII. Concurrency, IX. Disposability, XII. Admin processes

Execute the app as one or more stateless processes, Export services via port binding, Scale out via the process model, Maximize robustness with fast startup and graceful shutdown, Run admin/management tasks as one-off processes…

All of these are taken care of by Docker and sometimes facilitated by Docker Cloud.

Links