Top 5 Developer Best Practices for Financial Services

Agile planning, source code management, automated quality processes, and testing for proper configuration are all vital to financial services application developers’ success.

financial services

Developers who work for a financial services provider have it even harder than ever in today’s data-driven, hacker-plagued digital world. Data security is top of mind among most CIOs and CTOs; sloppy code from a development team could result in a high-profile data breach and could cost the organization millions – even billions – of dollars. Beyond that, financial services organizations must comply with a host of government and industry regulations – for example, The Bank Secrecy Act (BSA), which requires banks to review transactions for possible fraud and report them to the federal government. This adds additional complexity to everyday tasks.

DevOps is commonly defined as a software development methodology that combines software development with IT operations. The goal is to shorten the development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.

Putting DevOps into practice is an ongoing experiment for many organizations, even beyond the financial services industry.

Release Day: The Struggle is Real

Developers often struggle with continuous integration (CI) or continuous delivery (CD) performance, testing delays and other bottlenecks. In fact, one survey reported that only 34 percent of projects finish on time and only 42 percent come in on budget. Security and development teams must collaborate to keep up with the rapid development life cycle without sacrificing security with every update.

Enterprise SaaS apps are not distributed like traditional software – they are continuously running services. So CD is all about updating the service with a set of changes. In public clouds like AWS and Heroku, this is done through pipeline stages (e.g., dev, test, staging, and production). In platforms like Salesforce, stages become sandbox environments, ephemeral Scratch Orgs, and Production Instances.

The Top Five Developer Best Practices

How can development teams across the financial services industry shorten the development life cycle without sacrificing the integrity of the features and updates? We’ve outlined the top five developer best practices:

1. Advanced planning ensures all boxes are checked

Agile planning is now de rigueur for enterprise development. It is best used if the product itself will most benefit from flexibility; if regular face-to-face interactions and collaborations are needed between team members; when the end product requires regular updating, monitoring and continuous delivery to the client throughout the lifecycle.

For CD, ensure your user stories are sized correctly and that each story rolls up to an Epic that represents a stand-alone feature. This enables your team to release bite-sized pieces of functionality that are consumable by users and traceable back to your release plan. Also, define acceptance criteria for use in the verify stage so you know when something is done-done. 

2. Manage the source code, especially when working in a shared environment

There are a few practices of app creation that impact CD. First, source code is not the only element of an enterprise solution. Schema, User Interface, Access Control Rights and Static Resources like icons and images are all part of the creation process and should be managed just as diligently as source code. They should all be checked in to a Version Control System (VCS) as a single source of truth.

Second, ensure that developers are making changes in a segregated environment. In some low code platforms like Salesforce.com this becomes a challenge, but even in a database, multiple Database administrations (DBAs) can step on each other’s changes when working in a shared environment.

3. Automated quality processes are difficult to implement, but essential

Selenium is a great tool for testing functionality and should be part of your practice. But there are several verifications that should be made before you get to functional testing. Static code analysis tools like PMD are essential to ensure your development team is coding against a single style.

Define a team style and enforce its use. Unit test coverage is also essential – incorporate them with a coverage of at least 75 percent. Finally, after these automated tests pass, implement a manual peer review. Old hands are able to spot opportunities for performance improvement where automated tools may not.

4. Changes should be released in a defined pipeline with strict quality gates

Packaging for CD is about capturing changes that can be incrementally released into the next stage or environment. Development teams should dedicate a branch for each stage and bundle incremental changes into a promotional branch in order to leverage the merge conflict detection in your VCS.

Changes should be released in a defined pipeline with strict quality gates that ensure the verification steps and enforce the order of release stages. Developers should not be able to bypass key stages throughout the development cycle –  for example, moving from Dev to Prod.

Focus on making smaller changes, which result in reliable, predictable releases. Finally, be sure to automate promotions. This enables your team to validate the promotion scripts in Integration, Test, and Staging before releasing to Production which decreases the likelihood of an unhappy surprise.

5. Automate configuration, especially for end-user access rights

Make testing for proper configuration part of your verification process. Platforms like Salesforce have powerful profiles and permission sets that enable user access to only the right information. Improper configuration can expose personally identifiable information (PII), credit card numbers, or other personal data. 


SHARE
David Brooks
David Brooks is Vice President of Products at Copado. A leading mutual life insurance company uses Copado to automate code testing, gain full visibility and the ability to track any failures. As a result, the company’s delivery team was able to implement structured releases and scale the developer team from 30 to more than 130 developers.