• Overview
    Key features
    • Observability
    • Auto-scaling
    • Multi-framework
    • Security
    Frameworks
    • Django
    • Next.js
    • Drupal
    • WordPress
    • Symfony
    • Magento
    • See all frameworks
    Languages
    • PHP
    • Python
    • Node.js
    • Ruby
    • Java
    • Go
  • Industries
    • Consumer Goods
    • Media/Entertainment
    • Higher Education
    • Government
    • Ecommerce
  • Pricing
  • Overview
    Featured articles
    • Switching to Platform.sh can help IT/DevOps organizations drive 219% ROI
    • Organizations, the ultimate way to manage your users and projects
  • Support
  • Docs
  • Login
  • Request a demo
  • Free Trial
Blog
Thumbnail

Production is an artifact of development

symfonydrupalphppythonruby
23 December, 2016
Larry Garfield
Larry Garfield
Director of Developer Experience

In my former life I was a Drupal consultant and architect with Palantir.net. One of my former colleagues there, Michelle Krejci, had a saying she liked to repeat: “Production is an artifact of development.” She even presented on the topic a few times at conferences. What she was saying made sense, but I didn’t fully grok it at the time.

Now I do.

As a PHP developer of 15 years, I like many developers had gotten into the habit of deployment being a question of “put code on server, run”. That’s PHP’s sales-pitch; it’s the sales pitch of any scripting language, really. The same could be said just as easily of Python or Ruby. What is an artifact of development other than code?

Quite a lot, of course. Developers in compiled languages are used to that; source code needs to be compiled to produce something that can actually run. And as long as you have a build process to compile code, throwing other tasks in there to pre-process the source code, or generate other files, is a pretty short leap. For scripting language users, though, that is a weird concept. Isn’t the whole point of a scripting language that I don’t need to compile it?

Well, yes and no. While PHP or Python execute “on the fly” as needed, that doesn’t mean other parts of the system do the same. Sass files need to be converted to CSS. Javascript is frequently written in a non-runnable form these days (TypeScript, ES6, CoffeeScript, JSX, or a dozen other forms) and compiled into ES5-compatible Javascript. Even if you’re not using a code generator or transpiler or whatever is in vogue these days, almost any serious project is (should?) be using CSS compression and JS compression to reduce download size.

And let’s not forget 3rd party dependencies. Any mainstream PHP project these days is built with Composer. Python uses pip, but the effect is the same. 3rd party dependencies are not part of your code base, and do not belong in your Git repository, but are pulled in externally.

On top of that, many systems today do have a PHP code generation step, too. Symfony’s Dependency Injection Container and Routing systems, Doctrine ORM’s generated classes, and various others all entail turning easy-to-edit-but-slow code into uneditable-but-fast code.

For years I’ve been largely avoiding such tools, because I worked mostly with either heavily-managed hosts that had no support for such steps (or their support was far too hard-coded) or client-hosted servers that still believed in hand-crafted artisanal server management. Short of checking the generated CSS, JS, and PHP code into my repository (which we did with Sass/CSS for years), there wasn’t much way to square the clear shift toward even scripting languages having a compile step with the 2005-era thinking of most of the servers I used.

And then I found Platform.sh.

From the very beginning, Platform.sh has been built on the “production is an artifact of development” model. Your application doesn’t consist of just your code. It’s your code, plus 3rd party code, plus your server configuration, plus some CI scripts to generate CSS, compressed JS, optimized PHP, and so forth. Platform.sh was built specifically to address that modern reality. Your git repository may only contain your code, but that gets turned into, repeatably and reliably, a set of application containers, service containers, and “output code” that will actually get run. What that process looks like is up to you and your application; it could involve Sass, or not; compiling TypeScript, or not; dumping a dependency container or routes, or not.

The compiled artifact of development isn’t just your code; in fact it’s not even an application container that includes your code. It’s the entire constellation of tools that form your application — your code, your database, your cache server, your search index, etc. That’s exactly how Platform.sh works, and why it offers far better support for modern web applications than any other managed host I’ve used. (Give it a spin.) And no, I’m not just saying that because I work here. :-)

So thank you, Michelle, for convincing me of what modern web hosting should be. And thank you Platform.sh for making it a reality.

Get the latest Platform.sh news and resources
Subscribe

Related Content

DrupalCamp Florida 2024: sharing takeaways from the experts

DrupalCamp Florida 2024: sharing takeaways from the experts

Company
AboutSecurity and complianceTrust CenterCareersPressContact us
Thank you for subscribing!
  •  
Field required
Leader Winter 2023
System StatusPrivacyTerms of ServiceImpressumWCAG ComplianceAcceptable Use PolicyManage your cookie preferencesReport a security issue
© 2024 Platform.sh. All rights reserved.
Supported by Horizon 2020's SME Instrument - European Commission 🇪🇺