- Wasted time troubleshooting environments
- Wasted time trying to reproduce code bugs when the problem actually lies in misconfigured environments
- Developers on call to “fix their code” in production
- And so on
“Works on my machine” is a common refrain heard whenever the local environment configuration (from dev to test to production) has drifted from the established baseline. This drift can be due to a number of factors, including:
- Readmes and Wikis – organizations commonly document their environments using a Readme file and/or a Wiki article. Unfortunately, these static files are rarely updated in sync with changes to the evolving runtime environment.
- Lack of Programmatic Reproducibility – environments that are built on the fly from a configuration file that does not lock dependencies at all levels (ie., transitive dependencies, and OS-level dependencies) can drift over time.
- Lack of Insight into Production – the more that developers are distanced from production and even test or CI/CD environments which are the sole domain of Ops/DevOps personnel, the less proactive they can be to help ensure environment consistency.
Top 10 ¯\_(ツ)_/¯ When Applications Don’t Work As Expected:
- You’re doing it wrong
- Why do you want to do it that way?
- There’s currently a problem with our hosting company
- It probably won’t happen again
- How is that possible?
- I’m not getting any error codes
- Our code quality is no worse than anyone else in the industry
- It’s never done that before
- It must be a firewall issue
- It works on my machine
Generate your own excuse at http://developerexcuses.com/
Organizations need a better way to proactively ensure environments are configured correctly across the entire software development process, from development to test and CI/CD, as well as through staging and production.
How to Manage Configuration Drift
Whether environment configuration differs within a team (ie., from developer workstation to workstation) or across teams (ie., between development and CI/CD environments, for example), the result is the same: the application works fine on some local system, but fails to run properly on a different system.
Common solutions that organizations use to address these kind of “works on my machine” issues include:
- Containers – at one point, containers were heralded as the panacea for all issues plaguing the software development industry, but most organizations have now tempered their expectations. In the case of “works on my machine” issues, containers are just another deployment target whose environment needs to be properly configured.
- More Testing – this is an insidious solution since what code wouldn’t benefit from greater test coverage? But the problem with “works on my machine” issues is that they’re almost always corner cases, and thus extremely hard to test for in any deterministic way.
- More Frequent Code Delivery – cranking up your CI/CD cycle to deliver more candidates to your staging environment is one way to catch “works on my machine” issues, but it’s still not proscriptive, and really just comes down to “trial and error” testing.
- Governance – a two-edged sword that typically means “improved processes” to managers and “more roadblocks” to developers.
While these are all logical areas to examine for improvements in your software development process, they effectively paper over the real issues, which more often than not lie either in your dependency management process or collaboration methodology, both within and between teams.
In practice, whether you’re working locally or in the cloud, “works on my machine” issues ultimately boil down to three principal problem areas:
- Control – just as too many cooks spoil the broth, too many build engineers can spoil the environment. But care has to be taken to ensure that a single point of focus doesn’t also become a single point of failure.
- Dependency Management – ensuring that all the dependencies – from top-level dependencies to transitive dependencies to operating system dependencies – are consistent from deployment to deployment, no matter the environment.
- Collaboration – ensuring that development, test, and production teams are all working with a consistent, common environment configuration, rather than trying to independently create and maintain their own.
Runtime Environment Control & Collaboration
The ActiveState Platform is designed for collaboration, and can provide your organization with a significant head start when it comes to creating, managing, and updating runtime environment configurations:
- The ActiveState Platform acts as a single source of truth for the runtime environment your developers, DevOps, and Ops teams can centrally access and deploy to their environments.
- Branching allows you to create parent-child versions of your configuration for each target deployment, with any changes being inherited to ensure consistency.
- Role-Based Access Control (RBAC) allows you to designate which stakeholders can create, modify, or just use the runtime environment for their purposes.
Our customers typically use the Platform to create a centralized registry of approved packages and dependencies that are controlled by a single author, but that developers can freely download and modify on their local systems. This provides for central control while giving developers the freedom to work in their own sandbox.
See how it works:
To see how you can create different branches for different deployment environments using a parent-child inheritance model, watch our video on Reproducible Environments.
Next steps:
The capabilities shown here are also available as a managed service, freeing up your developers to focus on coding and getting your product to market faster. Learn more about our Managed Builds service.
Continue reading:
- Read our datasheet: The State of Package Management (and How to Make It Better)
- Read our datasheet for coders: Advanced Package Management
- Read about: Optimizing CI/CD implementations in your organization
