CC-NC-SA-BY 4.0 By Patrick Savalle
- Review and check all the items
Contents:
DevOps is an iterative and incremental software development approach with emphasis on autonomy, automation, continuous improvement and collaboration (loose definition).
This template is constructed as placeholder for different specialized methodologies.
- Planning method
- Branching strategy
- Design guidelines
- Coding guidelines
- Versioning strategy
- Developer Testing strategy
- Operation Method
- Monitoring and Observability Strategy
- Incident management procedure
- Rollback procedure
- Disaster recovery procedure
See:
-
Adopt LSD/LEAN as your agile philosophy
-
Establish a culture of efficient, open, blameless communication
-
Never go dark, never assume, communicate with appropriate stakeholders in all phases of the project
-
Enable projects to function autonomously and self-organising (self-service, architecture, governance)
-
Plan in ever shorter increments and optimize in ever shorter iterations until everything is continuous
-
Include end-users in the learning loop as soon as possible but no later than the MVP
-
Use crowd sourcing instead of team sourcing as much as (security-wise) possible
-
Everything is code
-
Everything is automated
-
Everything is tested
Systems are made up of interconnected subsystems (partitions or parts), this is called modularity. Parts have natural low coupling externally and high cohesion internally.
A selection of the system based on functionality present across multiple subsystems is called an aspectsystem or (aspect).
Examples:
- the rooms of a house are subsystems, the electrical wiring and the plumbing of a house are aspectsystems
- the RGB-pixels of a display are subsystems or parts, all red pixels of the display form an aspectsystem
Parts of modular systems have a natural mutual order visualized by a directed graph. This dependency graph visualizes how changes propagate and what is the most efficient order in which to build the system. To determine this order:
- Modules with no outgoing dependencies have layer 0
- A module's layer number is the longest path to layer 0
- Modules that have mutual / cyclic dependencies are on the same layer
- The system must be build in ascending order of layers
The Modularity Principle states that programs should be built from cohesive, loosely coupled modules in order of their dependencies. Modules translate to increments in the planning.
Workflows are made up of increments that sequentially add new parts or aspects and iterations that repetitively improve existing parts or aspects. Increments generally make systems more complete based on feed-forward (design), iterations generally make it more perfect based on feed-back (bug reports, performance issues, enz.).
Complexity is roughly the result of quantity, diversity and coupling. it can be managed with:
- Divide-and-conquer
- White-box / blackbox strategy
- Encapsulation
- Patterns or symmetry (reducing diversity)
- Abstraction
Functionals are the system properties that the end-user interacts with to perform tasks.
Non-functionals are the properties that give a system reliability, security, scalability, robustness, maintainability and changeability.
Changing a system’s modularity without changing its functionality is called refactoring.
Reasons to refactor a system include:
- accommodate large changes in requirements
- making parts of it reusable in other systems and improving changeability
- restoring drift from ideal functional modularity caused by agile (design-less) project planning
To make (implementation) complexity manageable it needs to be hidden, encapsulated by an interface. Users only need to see the ( simple) interface, not the (complex) implementation.
A good interface is:
- Minimal
- Complete
- Opaque (it hides implementation details)
- Self-explanatory
- Consistent
- Documented
Development collaboration in DevOps is done using a task board. Scalable collaboration means stories and tasks on the board can be crowd-sourced, beyond the teams. To make this collaboration scalable (distributable):
- tasks must be isolated, without too much context
- tasks must be small, to stay mergible back into the collective
- tasks must be unassigned, so that anyone can collaborate
- tasks must be independent, so many can be done in parallel
- tasks must be on some kind of open marketplace / platform
- only simple rules are needed to collaborate
- no direct (same time, same place) communication is necessary
Some examples: both Git and Kanban are scalable. Scrum is not. Bug fixing is scalable, feature coding much less so. Etc. Good design helps scalability of collaboration.
See stigmergic collaboration for some theory.
- Errors can cause problems
- A defect is an error in the specification and a potential problem
- A bug is an error in the code and a potential problem
- A problem is an actual misfunctioning caused by an error
-
Product quality
- Functional Suitability
- Performance Efficiency
- Compatibility
- Usability
- Reliability
- Security
- Maintainability
- Portability
-
Quality in use
- Effectiveness
- Efficiency
- Satisfaction
- Freedom from risk
- Context coverage
See ISO/IEC 25010