Take the 2-minute tour ×
Tridion Stack Exchange is a question and answer site for Tridion developers and administrators. It's 100% free, no registration required.

Is there a way to use Tridion to publish and keep a historical, 'rollback-able' record of 1 or more dll's that are required for a website?

Since Tridion tracks/controls the pages, static content, I would assume that there should be a way to track/control publishing of code as well.

The situation is as follows..we have a team that handles front-end dev(gui) and a team that handles back-end dev(programmatic templating, .net coding, etc).

Revisions to the site usually require the following: Publishing objects via Tridion Building and copying .net dll's via file system.

Here are some possible problems with the current scenario.. A missing dll could break the build. An old dll could break the build. If we need to roll-back a build, need to track what dll's need to be rolled back as well.

So, we are using code repositories to maintain .net code, which would be fine if the .net code did not rely on Tridion and vice versa.

If, in addition to the CMS and the code repository, there was a system that would track all members, that would be best.

We have not yet implemented Bundles/Workflow -- possibly that contains the features I require?

share|improve this question

migrated from stackoverflow.com Apr 24 at 1:52

This question came from our site for professional and enthusiast programmers.

1  
Most of the answers to this question are going to be "Sure you can, but you shouldn't". Having said that, I've seen real-life systems where deploying dlls to the web application was only possible through the CMS. Sometimes there are reasons for this - especially when the alternative is to publish the code and have it dynamically compiled on the front-end. Still - if you don't have constraints like that, you should be heeding the warnings (and perhaps even if you do have such constraints!) –  Dominic Cronin Apr 24 at 7:19
add comment

4 Answers 4

technically you can do this easily by making .dll as mime-type in CMS , publish dll as binary and configure to deploy to the CDA file system, but it is not a good practice from SDLC and not recommended in my opinion. best practice point of view, DLLs should go through code repository and build/deploy process. Any decent source code repository will provide versioning, branching and rollback capabilities.

share|improve this answer
add comment

As @Ram already answered, I want to add few more points to it.

Maintaining and publishing of website Dll's on Tridion is not a best practice.

For these activities, we have Source Control and Versioning tools such as SVN, VSS, TFS and soon. Using these tools, you can rollback & rollforward your code and build & publish the website project. Take the Dll's & respective code to deploy on the servers.

If you don't want to do manual deployment, you can write your own build script for auto deployment on the servers.

share|improve this answer
add comment

At the most, consider tracking high-level releases (by ID), maybe using metadata and keywords (or AppData) to document how content or pages relate to dll releases. A simple GUI extension can show your release details in Tridion's GUI as well.

These Tridion (2013) features could help with the "project management" part of Web content management:

  • Bundles and multi-item Workflow
  • External Content Libraries
  • Even Tasks to communicate across CMS groups

In terms of best practice and requirements, keep in mind delivery-side Preview code should probably match Live for each CMS environment. And since delivery is relatively version-agnostic, Tridion won't do much more than more typical build approaches without:

  1. A way to promote the dlls up through CMS environments
  2. A way to confirm Preview and Live match

So publishing one dll to Production Live is easy. Tracking multiple versions of it across a full setup (up to 8 environments) along with the security concerns might not be worth it.

share|improve this answer
add comment

Reading through the answers provided thus far, I guess the correct answer is "yes you can, but you shouldn't".

As someone who has used both approaches, I just wanted to add a couple of ideas/comments:

Pros

  • Ability to deploy code without access to Production. Tridion already has access to update files on delivery server, a dll is just a file.
  • Built-in versioning
  • Content-portable between Tridion instances
  • Very little work needed to set up a new server. Add a deployer, then publish.

(I even went as far as storing jar files in Tridion too, upgrading Tridion was a question of republishing everything).

Cons

  • Ability to deploy code without access to Production. (Yes, I know this was listed as a Pro too)
  • Tridion was not built for this. You will have issues, and you'll be on your own to fix them
  • Some application servers really hate when their run-time files get changed
  • IIS likes to stop everything and recompile the whole site whenever it notices too many code changes. On a large site, this can be a serious performance hit.
  • Anti-virus on windows machines tend to be annoyed with dll files changing too.
share|improve this answer
    
IIS likes to stop everything and recompile the whole site whenever it notices too many code changes. On a large site, this can be a serious performance hit. - Any change to the bin directory of a web app will cause an app pool recycle (presuming that's what you mean by "recompile") so strictly speaking this isn't really a con unless your binaries are being published more often than necessary. –  Ant P Apr 24 at 19:36
    
No, it actually does recompile the whole site, especially if you're publishing ASPX/webforms. This almost explains it all msdn.microsoft.com/en-us/library/ms366723%28v=vs.100%29.aspx, my observations at the time were that IIS would recompile only certain folders (fast operation) and eventually "give up" and recompile everything. –  Nuno Linhares Apr 24 at 19:42
    
Again, though, dynamic compilation of aspx files, App_Code and other uncompiled site resources will reoccur whenever the bin folder is touched, so the same point applies - unless you're in a position where people are publishing (or can publish) binaries out more frequently than necessary, this is no more an issue than it is with any deployment of binaries. –  Ant P Apr 24 at 20:51
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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