Most developers are aware of the inherent risks of working directly in production. Yet, some organizations resist adopting a development / production model – have separate development and production environments – citing concerns about flexibility, speed, and necessity. While setting up and using this dual system may seem daunting, the benefits far outweigh the challenges.
In this article, we’ll break down these key reasons why adopting a development (dev) environment setup is essential for long-term success.
One of the strongest arguments for having separate development and production environments is the ability to prevent cascading errors. When developers work directly in a production environment even small changes – such as modifying a value list or adding a new field – can have unintended consequences. A single misstep can lead to cascading failures, impacting users and business processes.
We’ve seen this cascade occur on more than one occasion, most recently when a client, who was also a developer, was modifying a script in their live solution. The script got stuck in a loop which soon caused the server to crash, interrupting the work day of about fifteen staff, plus numerous people who accessed the system through WebDirect.
In a development environment, modifications can be safely tested before rolling them into production. This safety step prevents scenarios where a seemingly minor change results in broken scripts, corrupted data, or issues that take hours (or days) to untangle.
Working directly in production often limits a developer’s ability to experiment. There’s an inherent risk aversion when making changes in a live system. Developers become hesitant to test new approaches or optimize workflows because they fear causing disruptions.
A development environment fosters innovation by allowing developers to experiment, iterate, and refine solutions without fear of breaking production. This freedom leads to more creative problem-solving, better performance optimizations, and ultimately a more stable and efficient application.
Before a new system is deployed, a development environment can also be used for prototyping. This step allows developers to provide new clients with a more hands-on representation of what their completed solution will look like.
A structured development environment enables a clear testing workflow. Ideally, the process should follow these steps:
This process ensures that all updates are tested in a controlled setting before being pushed live. Without this structure, testing often happens in production, where any mistake can immediately impact business operations.
When issues arise in production, everything becomes an urgent hotfix, especially for the client. Without a dev environment, developers often find themselves making on-the-fly corrections without a chance to properly validate their solutions. This approach leads to:
A development environment provides a safety net where issues can be thoroughly tested and resolved before they impact end users. It also introduces a clear path of ownership and documentation, making it easier to track and resolve issues methodically.
When issues occur in production, debugging can be a nightmare. Without a development environment, developers must troubleshoot live data, making it difficult to determine what changed, when it changed, and who changed it.
A dev environment allows developers to:
This approach significantly reduces the time spent investigating problems and provides clear evidence of what was tested versus what is currently in production.
In an environment where multiple developers are working simultaneously, a development environment is essential. When multiple hands are making changes directly in production, it’s easy for updates to conflict, overwrite, or introduce unexpected dependencies.
A dev environment provides:
Users rely on consistency in order to master their custom-built solution. However, over time, added functionality can require adjustments to the user interface. With a development environment, users can become acquainted with and better adapt to changes in the look and feel of the system, making it easier for them to transition once the update is deployed.
Additionally, as new versions of FileMaker are released, new user interface options may become available that improve the user experience. Experimenting with these new features in the development environment provides an opportunity to identify all the layouts that will require updating.
One concern raised about a development environment is data migration. While it’s true that a dev copy doesn’t directly facilitate data migration, it does help with testing structural changes before they are implemented in production.
There are free third-party tools, such as OttoFMS, as well as Claris’ Data Migration tool that provide an easy transition from the dev to the live environment with limited downtime for users.
Within the development area, developers can:
By catching potential issues early, developers prevent production data from being corrupted, avoiding unnecessary downtime or data loss.
In a perfect world, every change made to a system would be thoroughly documented, tested, and approved before deployment. A development environment helps enforce this best practice by ensuring:
When an issue arises, developers can quickly compare the production environment with the last tested version, making troubleshooting more efficient.
While working directly in production may seem more convenient in the short term, the long-term risks far outweigh the benefits. A proper development/production setup provides a structured approach to testing, debugging, and deploying changes while reducing errors, improving accountability, and fostering innovation.
Claris’ Data Migration tool, as well as other free migration tools like OttoFMS, make it easy to deploy development versions to live systems.
For FileMaker developers and any organization relying on database-driven solutions, implementing a development environment isn’t just a best practice – it’s a necessity which ensures system stability, data integrity, and efficient team collaboration. By adopting this approach, teams can work more confidently, reduce downtime, and deliver a higher-quality user experience.
If you’re still on the fence about implementing separate development and production environments, consider the challenges you’ve faced with live testing in production. A structured environment will mitigate these challenges and set you up for long-term success.
We’re happy to answer any questions you may have about creating a more robust approach for your FileMaker solution. Contact us today or schedule a free consultation.
Your email address will not be published. Required fields are marked *
Comment *
Name *
Email *
Website
Post Comment
