Software Development Process
DjaoDjin recognizes itself amongst the people supporting a new breed of independent entrepreneurs. We are committed to maintain the software stack customers sites rely on fully available as Open Source. At the same time, the data gathered in production is highly sensitive, and falls under various regulations such as General Data Protection Regulation (GDPR) or Payment Card Industry Data Security Standard (PCI DSS) for example.
To reconcile a wide range of software developers using, experimenting and contributing to the Open Source repositories with the strident security, confidentiality and reliability constraints of hosting Software-as-a-Service products on the Internet, two roles exist within the organization.
Application Developer
Operations Engineer
We, at DjaoDjin, like freedom. We like to give people working with us the freedom and flexibility to organize their work around their own life. As a result the Application Developer role is setup in such a way that anyone can contribute under short-term contracts ( 1099 independent contractors in the U.S). Application Developers are responsible to add features and improve the code base of upstream projects on GitHub, usually on a very loose time schedule.
We, at DjaoDjin, care a great deal about supporting our partners. Operations Engineers are the very few highly-trusted people with access to domain name service (DNS), hosting (AWS), and payment processor (Stripe) accounts. They have the responsibility to guarantee reliability, up-time and respond to incidents quickly and efficiently.
Application Development
Application development is done through pull requests (PRs) on GitHub that are peer-reviewed and merged into an upstream repository. The expectations are:
-
Commit messages are informative. If they reference an issue, include the issue number in the commit title.
-
Pylint (config file) and eslint (config file) reports have been addressed.
-
Pull Requests are clearly labeled as "Work-in-Progress" (WIP) for early feedback outside a formal code review, and "Depends-on" for features implemented in other repositories and yet to be releases in an official package. Pull Requests that are not label-led as either "Work-in-Progress" or "Depends-on" are assumed to be ready for code review and being merged.
Code reviews
The purpose of the code review process is to minimize the technical debt accrued by merging the pull request. The guidelines code reviewers need to watch out for are:
-
Does this code introduces a security hole?
Security concerns are blockers. A pull request will not be merged when a security issue has been identified during a code review.
-
Will this code degrade performance of a production system?
Performance concerns that can be resolved at a later time without impacting the API schema, or documented workflows users rely on, might be acceptable. It is a code reviewer's call.
-
Will this code break backward-compatibility in either API signature or user workflows?
If backward-compatibility cannot be maintain, all approaches that could have maintained backward-compatibility should be documented as to why they were rejected. It is better to break backward-compatibility on new features sooner. The longer a feature has been in production, the more thoughts should go into finding a backward-compatible solution.
-
Is this code consistent with the rest of the software stack (API signatures, Django and Django-restframework conventions, etc)?
A sense of elegance usually leads to less bugs and more reliable software. None-the-less inelegant code is not a blocker if it reinforces the level of engagement of the application developer making the pull request. It is a code reviewer's call.
-
Is this code introducing a new prerequisite? Is it implementing a solved problem?
Standardize on a handful of third-party Open Source libraries whenever possible. Pay attention to licenses.
Operations Engineering
Operations Engineering is organized around the following guidelines:
-
RESILIENCE BY DESIGN
Always Assume something will break. Always design tools and processes to recover from situations that could not possibly happen.
-
MONITOR
Mechanically integrate and gather metrics at every step.
-
AUTOMATE
There is no one off, everything is scripted. Scripts are run periodically, mechanically.
Operations Engineering is done through downstream repositories which are as close as possible clones of the respective upstream repositories.
It is the responsibility of the Operations Engineers to assess when to pull upstream changes, commit local hot-fixes and communicate back production-enabling changes back to the upstream repositories.
Automated Tests
Code is packaged, deployed to staging environment and tested mechanically through a buildbot (Jenkins).
A new release cannot be deployed to production until all tests are passing.
User Experience Checklist
Many features, especially around the dashboard, require a person to check artifacts introduced on various browsers or screen sizes. This includes elements that seem to jump around as a page loads, or text which feels at the wrong place, too big, or too small for example.
A tester must go through the checklist written into a spreadsheet before a new release can be deployed.
Deployment plan
It happens regularly that databases need to be migrated, DNS records updated or other potentially disruptive tasks synchronized with deploying a new release. In those cases, a plan should be written as a list of steps and exact commands to be before deployment is started. Whenever possible the deployment plan should be first run against a staging environment.