@bogdancostea
software developer and technical lead
10+ years experience
Java, .Net, ruby
desktop, rich client, web
infrastructure and test automation
multi-language, multi-region deployments
agile and lean methods
Â
there's no place like home and no environment like production
this is the place where your app was meant to be, it was born to go live
Â
every step you took since the first user story, the first screen mockup and the first line of code has been directed at this one point - deployment to production
Â
we like to build things fast so we tend to forget that the things we build are not meant to be built, they are meant to be used
being agile, we accept change, and when it happens, we want to do it fast, and above all, we want it done right
the best way to ensure that it's both fast and right is to have separated and as-automated-as-possible environments
Â
these typically include:
Â
depending on your flow you may have more environments, such as staging, acceptance, demo, etc. - that's up to you
Â
for this talk we'll simplify everything and focus on the production and development environments - this is meant for brevity
Â
so where's the problem?
everything is fine and dandy until you realize that for a web app there's an inherent mismatch between different environment concerns
development
production
development:
production:
that's where the asset pipeline comes into play
Â
the role of the asset pipeline is to:
Â
when used properly, an asset pipeline will give you the best of both worlds
this should be done from the start.
Â
it's not impossible to do it on an existing codebase but if there are hidden asset dependencies of if the code expects some assets to be served in a specific way it's going to be really nasty...
Â
let's start
first things first - you need to separate your environments
Â
your build tool, whatever that may be, must:
Â
as a quick note, it's really good to have an automated build :)
your assets are source files
Â
these files, although most of them may be static must be treated as source files, checked in to version control
these files will not be served directly to clients
Â
this means that you must define 2 separate locations:
- assets location - this is where you pick up your assets for processing
- public location - this is where you output the result and where the browser has access to themÂ
the way that you code your assets, especially JS may make or break your process
Â
JS variables can and will conflict if you do not take into account that all your files will be concatenated and that the result will be loaded all at once
Â
also, you must take into consideration that various assets may have dependencies and that you should respect the dependencies when loading - use AMD, require.js
the pipeline usually consists of:
producing and using single JavaScript and CSS artifacts gets really useful when you cache them server-side and client-side
Â
well, this gets painful when you release a new version and you get mismatched versions of your artifacts because of cache refresh issues
Â
bumping versions on every release allows you to produce unique artifacts that have a different filename (fingerprinted), avoiding caching issues
asset delivery can highly influence user experience, so taking the following into account is a must:
before
after
Â
Â
speed is a feature
user experience is a feature
Â
don't let your users down
Â
Â
@bogdancostea