Hello, again!
This week's topic is
Environment Management : It's a Thing!
ENVIRONMENT:
You're a software developer, right? And before you get started on a project, before you write line one, you need some kind of environment.
I'm going to use web applications and PHP as an example, here, because I used to be a PHP developer. (image: shaaaaame)
In order to build a PHP application, you're going to need a web server, a database, php, and then various software packages to let all of those things know about one another. (mod_php, php_mysql), All of these things need to be running, and configured.
Most web applications, at the very least, require that you have some kind of application server, some kind of database, and some method of communication between the two.
LANGUAGE - APPLICATION SERVER - DATABASE - COMMUNICATION PHP - Apache2 + mod_php | MySQL | php-mysql C# - .NET + IIS | MS SQL | SQLConnection Java - Tomcat, WebLogic, WebSphere | Oracle | JDBC Python - uwsgi, Apache2 + mod_wsgi | MongoDB | pymongo
DATABASE MySQL PostgreSQL MS SQL Oracle MongoDB CouchDB
On top of that, as you develop your application, - if it's reasonably complicated - you'll add external libraries.
ENVIRONMENT: DEFINITION So, for the sake of this presentation, your application's environment is 'the list of things that you need, aside from your code, to make a working product'.
So, in the case of a standard web-application, your environment is composed of 'Language, Server, Database, and Libraries' -
But for a simpler app, your environment might just be 'Compiler'.
IN A LAND WITHOUT ENVIRONMENT MANAGEMENT: So, let's construct an imaginary project where the only person who knows how to set up the environment is the lead developer and maybe a system administrator.
(ISSUES:) NEW DEVELOPER
- A new developer joins your project, and he needs to set up his computer so that he can work with your codebase.
- He checks out your code base, and then... well, now what?
- In order to get to the point where he can do anything, new developer needs to set up his environment - so, he pages through the codebase, talks to the lead developer, consults online documentation, and generally dicks about until he has a mishmash of libraries and software packages that work well enough to get the code working.
INCONSISTENT ENVIRONMENT
- It could be that each developer on your team is deploying against a different set of libraries, a different version of the application server, or a different build of the database.
- So they can check something in that Works On Their Machine, but breaks for everybody else.
DEPLOYMENT
- And, finally, when it comes time to actually launch the software, to get that software running on a remote computer, nobody is totally sure how to do it. Once it gets deployed, none of the developers know how the 'live' system differs from their development versions.
MANY ENVIRONMENTS
- This is just for one project. Once a developer works on three or four different projects, they are likely to have three or four different environments installed on their development computer. It doesn't take long for that singular computer to be running two servers, three databases, dozens of peripheral programs... it gets complicated, is what I'm saying.
So, let's talk about Environment Management.
VIA DOCUMENTATION
Simply write down all of your application's dependencies - and instructions for installing and configuring them- as part of the documentation included with the application.
"In order to run this application, you will need X, Y, and Z."
This is manual configuration management - write good instructions and hope that your humans will execute the steps properly.
And it makes a good dent in all of the problems that we mentioned. New developers have a document to work from when they're setting up. The project's libraries are consistent between developers. And deployment is much easier.
So, if you don't take anything else away from this presentation, take THIS away. At the very least, you need to write down your dependencies.
Now let's look at how to improve on this.
GEM: TRULY OUTRAGEOUS
Many languages include tools to help you organize libraries for that language. Ruby has RubyGems, Python has PIP, C# has NuGet, Perl has CPAN, PHP has nothing...
With many of these tools, you can include, with your source code, a list of libraries and fixed versions that are required to run the software. People checking out the project can point their package manager at the list and have the system configure itself.
VIRTUALENV/RVM
WHEN ALL ELSE FAILS
If you can't find a reliable way to include a link to a dependency in your source control, you can always put the dependency itself into source control. It's not the best solution, but it's better than nothing.
MINI-ENVIRONMENTS
Many development environments come with developer-friendly mini-environments that focus on creating a workable system for developers without all of the trouble required to set up a complete environment.
Visual Studio, for example, contains a complete server, suitable for deploying IIS apps locally. Django's 'runserver' comes with a built in sample environment, as does meteor.js.
These have good qualities and bad qualities.
Good:
- Easy to set up.
- Consistent between developers.
Bad:
- Large gap between development and deployment environment.
- They often lean on 'light' technologies that do not act like those in production, like in-memory or on-file databases.
- If you want to use a slightly different technology stack, they're often difficult to change.
- Peripheral technologies often do not get consideration, forcing developers to manage an external environment anyways.
KEEPING ENVIRONMENTS SEPARATE
So, you want to keep your environments separate, so that you can use one dev machine for dozens of projects without worrying about running dozens of servers and countless software libraries on your system?
- VIRTUAL MACHINES Install a Virtual Machine manager and run a separate machine for every project.
\vagrant + chef