The cover image for this post is by Jandira Sonnendeck
This is part seven in our series of blog posts detailing our system for genius when working safely with legacy code. The other parts of this series include:
- A Series On Safely Navigating Software’s Timeless Artifacts
- Preparing To Tame Legacy Code With User-Led Odysseys
- Conversations with Code Custodians
- Why Documentation is Key to Legacy Code Success
- Before Running the Build
- Documenting your Progress
Introduction
In this seventh installment of the Unravelling the Code Tapestry series, we delve into the intricacies of accessing and securing a development database for local experimentation. We will discuss the importance of using a copy of the development database rather than live databases containing sensitive user information, as well as the management of credentials and environments to ensure safe and controlled testing.
Obtain Access to Credentials
Reach out to the maintainers of the legacy code base for access to the development database credentials. Ensure that the provided credentials are up-to-date and compatible with your local environment setup, ensuring security and separation of concerns.
You can test the credentials that you have been provided by using relevant database management tool, such as SQL Server Management Studio (SSMS) or Azure Data Studio. That way, you can feedback to the maintainers directly about any issues you might face when connecting to the database. This will help you to reduce friction when we get around to building and running the codebase.
Analyze Codebase Storage Practices
Investigate how the original development database credentials are managed within the code base. Ideally, these should be swapped out during automated build and deployments for different environments (QA, Staging, Live) to maintain security and separation of concerns.
If they are not swapped out during deployments, you might need to know how they are swapped out. Have previous developers been tasked with changing the credentials in the codebase before committing their changes to source control? If so, what is the process? And are the team open to swapping that process out for a more modern practise?
Host a Local Copy
Create a local environment with the necessary tools and software to host your copy of the development database. This will prevent accidental interference with other developers or live systems. This is especially important if you aren’t the only developer who will be making changes to the codebase, and everyone shares the same database instance.
This will also speed up the inner development loop (how long it takes you to go from writing a feature to seeing it running locally), especially if the new code requires database changes. Not only that, it will allow you to test the migration (and back off) paths without affecting any of the other developers or users of the codebase.
Beware of PII
Before working with the development database, ensure that any personally identifiable information (PII) has been removed to protect user privacy.
We are not legal experts, but we do know that being given someone’s PII can leave you at risk of relevant legislation. If you absolutely require access to PII, ask the maintainers about whether it is encrypted at rest and in transit. If not, you may need to rethink your database hosting strategy.
Ask whether any PII present in the database can be anonymised ahead of your receiving your copy of it. This will greatly reduce any issues with handling real PII.
Safely Access and Refactor
Iteratively refactor the codebase while running tests to validate your changes. This will ensure that you don’t end up being caught out by any assumptions about the format of any new database tables or entities.
Monitoring and updating documentation as needed can also help your colleagues (or the system maintainers) to understand, in real-time, the changes that you are making. It can also be useful four you to understand the context of your changes - remember: the “you” from yesterday and the “you” tomorrow have different contexts and information readily available.
Maintain Secure Environment Management
Keep track of how credentials and environment variables are managed in the legacy code base, making adjustments if necessary for safe experimentation. We recommend using a reputable password manager to help you keep track of the credentials and environmental variables.
If you are working external to the maintenance team (i.e. as a third-party), it is recommended that you get sign off for the password or secret manager to use - the team may have a pre-existing, pre-vetted solution they expect you to use.
This will also be very handy if you need to update any build and deploy instructions or automated workflows.
In Conclusion
Accessing a development database for local testing is a crucial aspect of ensuring a controlled environment while maintaining security and separation from live systems containing sensitive user information. To accomplish this, developers must obtain access to credentials from maintainers, analyze the original codebase’s storage practices for automated builds in different environments (QA, Staging, Live), host a secure local copy of the database, remove any sensitive data (PII) before working with it, refactor and test the codebase, and maintain robust security measures throughout the process.
By doing so, developers can create a safe and collaborative testing environment that promotes innovation and continuous improvement within their team.
If you’d like us to help you work through the challenges involved with working safely with a legacy codebase, either in a hands-on capacity or as a consultant, get in touch with the form below