System Development Life Cycle (SDLC)
The SDLC that is used within inSided has been adapted to the needs of our customers and allows our multidisciplinary development teams to work agile with an absolute focus on delivering secure, fast and feature-rich applications and architecture while maintaining full focus on our customers.
inSided has implemented an agile workflow for all development teams to ensure a smooth transition from idea to a fully tested feature on production. By handling the development work this way the developers are able to adapt rapidly to new priorities on a day-to-day basis, which is necessary to serve our customers with the agility they need in order to create successful communities.
inSided has built-in security and privacy checks throughout every stage in the development process. Via a strict protocol, in combination with regular internal (and external) audits by certified ISO 27001 auditors, inSided is able to ensure this protocol is followed while maintaining the flexibility to change requirements in the development process. This protocol enforces functional, security and load tests from the early stages of (technical) design up until the final deploy to the production environment.
DTAP (Development, Test, Acceptance, Production) is used to bring structure to the several phases on which deliveries and user acceptance tests are performed to the product teams. Test and Acceptance are non-scaled versions of the Production environment. The Acceptance level environments are available to our partners and customers to test integrations like SSI, SSO and API connections and making sure they work properly.
Within the development process, inSided identifies the stages below which are enforced by a continuously integrated pipeline in which code changes can only occur by using a pre-defined and automated process. inSided processes are reviewed bi-weekly by the development teams during a retrospective and optimized if necessary. All procedures are available in full detail for inSided employees via the inSided intranet.
The Product Owner creates functional requirements based on input from business requirements. These requirements can arise from different sources including customer requests, technical requirements/maintenance and general platform development requests from within inSided. In most cases, the IPB is notified of the functional requirements that are packed in a ticket (called an ‘epic’ in terms of Kanban) to decide if the ticket is corresponding with business needs.
Refinement and estimation
After the Product Owner finishes the functional requirements in an ‘epic’ or ticket, they are reviewed by one of the IT Architects. They ensure that threat/security assessments and load reviews are performed, prioritize and describe risks in regard to the new functionality and in which part of the system and code the change should be made in order to deliver the functionality. In most cases, the IT Architect and Product Owner meet directly to the developers within the development teams to ensure that both the functional and technical requirements are clear. During these meetings, the actual refinement and estimation of the amount of work are done including the discussion about what tests and (technical) documentation is necessary for the required functionality. This is mandatory before tickets can move through the pipeline to be worked on by the development teams.
The deliverables are (usually) created via TDD (Test Driven Development). Coding is done and architectural changes are made on the development and test environments at first. After changes are made to the code and/or architecture on the development environments they are sent to other developers via Pull Requests (PR). These PR’s allow developers to review and test each other changes by discussing the changes that have been made and asking questions about certain decisions. Only after a certain amount of approvals from other developers the changes are accepted onto the test environment where it will be extensively tested (both automatically and manual). Usually, the creator of the change and the persons who are responsible for approving the change do this.
inSided uses Continuous Integration (CI) as a way to ensure a smooth-running delivery pipeline. By ensuring that automated tests are added before/during/after the development of functionality inSided can maintain a stable platform without regression and a speedy development process. inSided uses automated tests for part of the system (Unit tests) but also end-to-end tests (Acceptance tests via Selenium) on a multitude of browsers/platforms. These include OWASP level tests including XSS, SQL-Injections, etc. and are performed on every code change (commit) to the codebase (see next chapter).
Manual Testing (QA)
The shippable deliverable is tested thoroughly by our Quality Assurance (QA) engineers. Testing is done with numerous tools and browsers to identify possible flaws in software and architecture. If a vulnerability is found or a test fails, the specific deliverable is put back into the development pipeline. In order to maintain an agile delivery pipeline inSided has chosen to make QA engineers part of the development teams. They are in sitting with the developers and can discuss issues when they occur. QA engineers are partly responsible for ensuring that the acceptance test coverage is correct and that edge cases are covered. QA engineers also check up on documentation (although it is not yet final in this stage) and give feedback. QA engineers have a list of standardized manual tests, which are always performed. This list is continuously improved when new functionality becomes available.
When the changes to the codebase are finalized the (technical) documentation should be delivered within the ticket. This is usually done via a shared document and/or internal development Wiki. In most cases, the documentation is already available and checked by the QA engineers. Note that in some cases there is no documentation is necessary and this step is skipped entirely.
Product Owner approval
When the deliverable is put to the staging environment it is production-ready including documentation, tests, and approvals from other developers and the QA engineer. The Product Owner's approval is the final stage before the actual release of the deliverable. During this approval, the Product Owner will look at the functional and business requirements of the ticket. The Product Owner can, in some cases, ask for a demo from the development teams to ensure that everything is as it should be. When the Product Owner approves the deliverable it can be deployed. If the Product Owner decides that the deliverable is not yet good enough a decision can be made to run it through the pipeline again or to make necessary (small) changes as a hotfix.
The deliverable has been fully tested and approved by the Product Owner. It will be released during the next release cycle, which happens several times per day. The deploy to the production systems is done automatically and includes a retest from the deploying developers. The development teams are able to deploy themselves and are directly responsible for the production environment.
The inSided development teams have a bi-weekly retrospective meeting in which they improve their way of working by focusing on better quality, speed, communication and take away any impediments. This review moment has led to a series of great productivity improvements for the development teams and ensures that technical priorities (like maintenance) are discussed during the IPB meetings.
inSided uses Continuous Integration (CI). It allows the development teams to ‘fail fast’ and continuously integrate each other’s code while developing new features. This is important when there are multiple development teams working on the same platform and codebase.
During the CI ‘builds’ are continuously created which test the new code changes in the system. Only if a build succeeds the change can move to the next phase. inSided developers are running the tests locally before the CI pipeline is actually used so failed builds are exceptional.
The builds are divided amongst several parts (repositories) of the system which are all tested on every change in the architecture and/or code on the test and staging environment in our DTAP street.
The inSided API cluster holds all architecture and functionality for the REST API that serves data to the application cluster, customers/partners, etc.
The inSided Application cluster holds all the applications and core functionality that is visible for end-users of the platform (including admins/moderators).
The inSided worker cluster holds all functionality to keep the architecture decoupled and ensures that the queues are always empty.
The inSided Search synchronization makes sure that all content in the relational database is synchronized with the search cluster that makes content available to our API and Analytics modules.
All of the above parts of the inSided architecture are automatically tested in the CI pipeline. However, also manual (QA) testing is performed to ensure that edge cases are also dealt with. The automated part of the testing includes at least these items:
- Lint check
- Unit tests
- Acceptance (end-to-end / OWASP) tests
- Mess detection
- Test coverage metrics
- Complexity metrics
- Duplicated code
- Code standards (PSR-2)