For any standard web project you will have server-side code, server pages, JavaScript and CSS files as your code assets. It's pretty standard practice for server-side code to have a test suite and a scripted build process to compile/package/deploy code. Builds usually go on a schedule after code has been tested and validated in a QA environment.

On the flip side, we frequently have a requirements to be able to push presentation layer code assets at will. Since they don't require compilation or restarts, this is feasible, but I'm of the mind that this code is coupled to the server-side code and is equally likely to destroy the whole site if it's broken. Therefore, it should never be pushed outside of a build cycle.

What is considered best practice for this?

3 Answers 3



We use C# + ASP.net at work and here are the reasons why not (They'll also apply to other techs, but I imagine in a slightly different format):

What happens if the UI references a control that doesn't exist?

-Big Yellow Exception.

What happens if the UI references an assembly that doesn't exist?

-Big Yellow Exception.

What happens if a JS file has code that references a specific DOM element that's not there?

-JavaScript Exception.

You can see the pattern here!

Anyway, why would you want to do a partial deploy? We use our CI server (TeamCity) to generate build artifacts for deployment, i.e. a complete pre-compiled self-contained website in a zip file that is simple extracted over the top of the old one. That way, any changes to config/js/css/images/whatever have to go through version control, so there's even less likelihood of things going wrong.


I don't care what side of the conversation the code/template/image/whatever is on. If it is part of the system then it is part of the system and needs to be managed and deployed like everything else.

Note: this is distinct from user-generated content which is supported by the system. That also may be version-controlled, but it exists in a different dimension from the system components.



Presentation code is code nonetheless. Just because it is interpreted rather than compiled doesn't mean it should have a free pass to duck the build process.

How do you ensure that developers make sure they duplicate these changes within source control? The live environment should match the code released from source control.

If a habit is made of making these little harmless changes then bugs will start to manifest.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.