DNA Project Base
A common base and set of workflows for creating and managing web-based application platforms
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.
Lets software engineers focus on the project-specific business logic – the “DNA”
Use Code Generation to save tons of repetitive work
What helps when wanting to focus on the core logic?
- Thin applications, fat dependencies
- Agile data modeling
- Event-based behaviors
- Configuration and model re-use
- Merit-based choice of components
- Codeception-based testing helper scripts
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
Because visuals are helpful
The Twelve Factors
And how it is taken care of in a DNA Project
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.
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.
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.
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.
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.
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.
VI. Processes, VII. Port binding, VIII. Concurrency, IX. Disposability, XII. Admin processes
All of these are taken care of by Docker and sometimes facilitated by Docker Cloud.