Software development best practices are “best practices” for a reason. For example, the best practice when beginning a new project is to create a new development environment for each developer on the project, preferably in a virtual environment, virtual machine, docker container, or similar isolated manner. While the reasons for isolating projects within their own virtual environments should be obvious to anyone who’s had to juggle parallel development efforts, let’s reiterate them here:
- Eliminates dependency conflicts with shared libraries.
- How many times have you run into a situation where project #1 requires version X of a library, but project #2 requires version Y? The same can be said for shared system resources, as well.
- Prevent sensitive information from being exposed.
- For example, Uber pushed code to Github that contained passwords for their live environment allowing anyone to access customer details. While the lesson is simple – don’t develop in production! – contrast this with what might happen if a developer working in their own environment were to release their dev keys on Github: embarrassing, but harmless.
- Minimize confusion.
- Whether you’re working on completely different software projects, different versions of the same project (v1.0 vs 2.0), or different releases of the same project for different platforms (i.e., Windows vs Mac), task switching should be as simple as switching between properly labeled environments.
While the above bullets seem like more than enough reason to follow best practices at the start of a new project, many of us still don’t. In fact, in ActiveState’s most recent Developer Survey, we found that while ~32% of developers start new projects on a monthly or more frequent basis, only ~14% build a new development environment for that project.
The problem lies in the fact that the pain of dev environment setup always looks like a much bigger time cost since it’s an upfront task, while the downstream headaches that will occur as a result of not setting up a new dev environment always look smaller because they’re farther off.
State Tool Streamlines Dev Environment Setup
ActiveState has released the first version of our Command Line Interface (CLI) in order to help reduce the pain of dev environment setup. Called the State Tool, it’s the client-side component of the ActiveState Platform, which is a cloud based system where you can either obtain a pre-built runtime environment (such as our Perl builds like ActivePerl, or Python builds like ActivePython), or else build your own runtime specific to your project. You can then use the State Tool to automate all of the tedious steps you usually go through when instantiating that runtime for your new project.
For example, issuing a single command like
state activate MyOrg/MyRuntime will automatically:
- Create a virtual environment on your workstation
MyRuntimefrom the ActiveState Platform and deploy it into the environment
You only require an internet connection to be able to pull down and deploy all required resources in a consistent, reproducible and isolated manner so developers can:
- Painlessly ensure best practices are followed
- Create a dev environment that’s consistent across the team, which means far less “works on my machine” incidents
- Automate a large chunk of the usual Project Startup Readme so they can get started coding faster
While the State Tool is currently only available for Python on Linux in preview mode (ie., we’re actively changing and adding features based on developer feedback), it’s envisioned that it will work on all major platforms, wherever your code is running, even in a container.
If you want to see how easy it is to get a new ActivePython dev environment up and running, just:
- Click here: ActivePython 3.6 to create an ActiveState Platform account and fork ActivePython into it
- Click on the Builds tab and select Linux from the “Platforms” choices
- Follow the commands under “Use via Command Line” to install the State Tool and setup the runtime:
And that’s it! The good news is you now have an ActiveState Platform account and can build custom runtimes for each of your projects. The bad news is that you no longer have an excuse for avoiding best practices.