RE: [Nant-users] Transactionality in NAnt

[Castro, Edwin Gabriel (Firing Systems Engr.)]

Title: RE: [Nant-users] Transactionality in NAnt

Seems to me NAnt is meant as a build tool not a deployment tool. A deployment tool certainly requires transactions. As a build tool NAnt does not need transactions although some of the things mentioned so far in the thread are certainly interesting and should be considered. My two cents.   --Edwin   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Byrd, Payton Sent: Tuesday, January 25, 2005 8:10 AM To: 'Nant-Users@Lists. Sourceforge. Net' Subject: RE: [Nant-users] Transactionality in NAnt   I agree that a build is not a deployment, but I do believe a build can be a component of a deployment.  Our team is trying to address a few issues with our current methodology of deploying via MSI files to a web farm: 1) Multi-homed servers that receive the same applications require manually configuring IIS for secondary websites. 2) Even using the GAC and Publisher Policy Files it is still possible to have dependencies that cannot be resolved at runtime without using the big hammer of the Binding Policy, which must either be configured manually or through manipulation of machine.config. 3) A failed MSI installation can introduce garbage to the registry that prevents assemblies from being removed from the GAC. NAnt allows us to build on the server and know for a matter of fact that all code that is built has all dependencies resolved, all unit tests performed and that the code will operate correctly at run time. However, NAnt introduces a new set of potential problems: 1) If a deployment (for any reason, including the automated build) fails then the GAC may have an incompatible set of assemblies since not all assemblies are given an opportunity to build and deploy. 2) If a deployment (for any reason, including the automated build) fails then the GAC or an application may not be installed leaving the webserver broken. Transactionality would solve both of these problems by automatically restoring the server to its previous state should a failure occur.  Even if you are not doing a build, but simply doing an install from NAnt then a failure can cause both of the above conditions to be true. To me, the true value of NAnt is its ability to perform a repeatable build process with an absolute minimum of human interaction.  In this world of Sarbanes-Oxley compliance, separation of duties rules requires that developers can not perform production deployments without following a very, very stringent set of logging requirements.  NAnt helps to fill those requirements by allowing developers to write code and create NAnt scripts, then everything goes through a code review, then systems engineers execute the NAnt scripts on the staging and production servers using the logs and unit test results to certify the results.  My team is not completely there yet as we are still structuring our NAnt scripts and support tools to achieve this goal. One of the functional requests from our engineers has been the ability to undo any damage caused by a failed build, thus the desire for transactionality.  As I said before, it can be accomplished with a lot of flags and a lot of spaghetti code in the NAnt scripts.  My request is that the core of NAnt be extended to support some new optional methods on tasks: OnFailure() : void OnCommit() : void This would allow a task to participate in a transaction.  This needs to be in the core set of interfaces of NAnt so that people can contribute upgraded versions of the core tasks such as <copy>, <gac-install>, etc that are used during deployments.  The runtime engine must also be upgraded to hold a stack of transactional tasks that would be called for either a Failure or Commit.  The runtime engine would also need a trigger mechanism, such as catching a RollbackTransactionException or something similar to trigger a rollback and would need to trigger a commit at then end of a build or possibly when a <commit> task is encountered. Transactions would have to be transitory between executions of NAnt so that when a build file is executed from another build file that the parent build file can be rolled back when the child build file fails. Payton Byrd Trane eBusiness QED Team Phone: 931-905-5386 Fax: 931-648-5901 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brad Wilson Sent: Monday, January 24, 2005 7:00 PM To: NAnt Users Subject: Re: [Nant-users] Transactionality in NAnt Sorry, but I disagree with general "transactionality". A build is not a deploy. If you choose to use NAnt for a deployment, then that's fine; you may want to approach some kind of transaction support for a deployment task that you might write for yourself. But for general build purposes, there's just not enough value in my experience. - Brad On Mon, 24 Jan 2005 14:53:38 -0600, Byrd, Payton <[EMAIL PROTECTED]> wrote: > I just finished reading the NAnt release schedule and noticed there are not > any documented plans for adding transactionality to NAnt.   ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Nant-users mailing list Nant-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users