Software Development
Introduction
At FundApps we believe in simplicity, automation and testing in order to deliver high quality software - and that follows through our entire software development process. Testing is a integral part of this - not only through our software development but also our rules team who implement the legal changes made around the world.
Security in project management
Information Security should be addressed for all FundApps projects that have a potential for impacting FundApps Information System or FundApps data as defined in the Data Classification and Protection Standard.
These projects must include information security requirements.
An information security risk assessment must be conducted at an early stage of the project to identify necessary controls.
Information security must be applied to all the phases of the applied project methodology.
Change Management Controls
Authorising Changes
Significant changes to the production environment are captured in Shortcut and are based on requirements made by FundApps stakeholders (Product Team, CTO, Head of Information Security, etc.) as illustrated in Figure 2. This process is described in a dedicated procedure available in FundApps knowledge sharing tool.
Testing changes
All changes are tested with a multi-level test suite (Front End tests, integration tests, unit tests, rule tests, static application security testing as well as Open Source Software License scans) as can be seen in figures 4, 5, 6 and 7. Changes cannot be applied to production if tests fail. Finally, a dynamic application security testing tool scans a client-like environment on a weekly basis.
Approving changes and Segregation of Duties
All changes to production can only be submitted by members of the Engineering team, Content and CS teams. Furthermore they need to be peer reviewed (Figure 3) and approved by a different staff member (based on the repository) than the one submitting the changes, before they can be merged into the main code branch, as described in the FundApps Code Review guidelines.
Emergency changes
All builds are stored allowing to rollback to the last known good build in case of an emergency.
Change Management Steps
Work item specified Work items are scoped and defined as development tasks in Shortcut. Potential security issues flagged and discussed at this stage. Items prioritised and tackled by the team (Figure 2)
Development work Development or configuration work is performed as scoped and defined in the work item.
Pull Request created Once the work is complete, or at intermediate stages for larger work items ‘pull requests’ are created (Figure 3). Pull requests specify the desired changes across files and act as proposals for specific change.
Change reviewed Every change is scanned for security vulnerabilities by a Static Application Security Testing tool. The changes contained within the pull request are reviewed by another team member for code review - both for quality, style and security (making use of the results from the Static Application Security Testing tool). More details on our review process are specified in FundApps' code review guidelines[Access restricted to FundApps staff]. Comments are placed on the pull request to drive any amendments that may be necessary.
Built by CI server All releases and pull requests are compiled on a build server, to check that the artifacts contained in source control are complete.
Unit Tests Run All unit tests contained within the test suites are run on the build server to verify that the release functions as specified in an isolated environment. This occurs both on pull requests and on the main branch (Figure 3 & 4).
Change merged to main branch Once the pull request has all tests passing and any identified changes to pass review have been made, the pull request is merged to main and becomes a potential release of the system.
Test Rule Content with release The test suite maintained for our legislative rule content is run using the logic and algorithms of the proposed new release to confirm behaviour and semantics are maintained.
Deploy to main testing environment The proposed release is deployed to a main testing environment, to validate that the release can be successfully deployed and that the resulting instance reports a healthy status.
Run Feature Tests A series of automated feature tests, using a scripted web browser covering the key functionality of the system are run (uploading files, viewing results etc). These establish that the proposed release loads correctly and performs the desired tasks.
Deploy to main staging environment The proposed release is deployed into a staging environment in our Production network (Figure 5). This verifies that the release can be deployed successfully with production configuration and infrastructure
Smoke Test A smoke test is performed by checking the health of the main staging environment and uploading a position file. This ensures that in the production environment, the system is able to accept uploads and process data.
Deploy to client performance environment If desired, or if the release presents questions regarding performance impact (identified during the pull request review), the release may be deployed to a specific performance testing environment to examine performance characteristics on the production network before availability to clients.
Deploy to client staging environment (automated) Given successful completion of all previous steps and check, a release is promoted to all client staging environments.
Deploy to client production environment (automated) Given that a release has been successfully deployed to a client’s staging environment, it is promoted to all client production environments. This process may be conducted for all clients sequentially.
Perform dynamic application security testing (automated) A client-like environment is scanned every week by a dynamic application security testing tool for vulnerabilities (cf. figure 8). Any potential vulnerability is managed through the process described in the Vulnerability Management Policy.
Last updated
Was this helpful?
