ColdFusion in an Enterprise Environment - Part 1 - Understanding how to use SubVersion (SVN)
Subversion can be used in many ways, so this isn't the holy grail of how you need to use subversion, but it does add application management to subversion. What does application management mean? Well, the definition for this article is how to control what gets released into production.
This article is not going to go into how to setup version, or how to add an external to the repository tree. But how in concept to use SVN and an external to achieve application management.
First of course you need a SVN repository, which for the purpose of this article our repository will be noted as "/".
Second we need to know that will we still be using the concepts of trunk, tags, and branches, they just won't live in the root of the repository. The trunk is the current working copy of development, while the tag folder is to version releases (by tagging). Branches will be used when "new" development is going on and emergency coding is required on the existing code base before the new development will be completed.
Lastly, we need to understand what will be in the root of the repository. These folders are instances, projects, and vendors. Therefore, the SVN repository will look like
/
instances/
projects/
vendors/
Vendors is any code not developed by our developers. For example, jQuery would be in the vendor location, therefore giving us the ability to manage what version of jQuery is in each environment. Each folder under Vendor, for example jQuery, should have a trunk, tag, and branch folders.
Projects is each sub-application in our product and it is each supporting product. For example our enterprise has a central account management API, which is only accessible through web services, therefore, a wrapper for that API will be project. While the product that uses the wrapper to the api is also another project folder.
Another example describing the separate project methodology is a shopping cart application, you'll have the cart, sales tax calculator, shipping calculator, billing information, and the shopping cart application itself. The proposed use of this would have each of those in separate folders so different developers can work on different areas in a unit testing methodology.
With separating everything the need for one "project" for the actual application still exists. Right now this requires the developer to know the relationships when extracting projects out of SVN. If a developer is required to work on the actual application, the developer would need to extract all other projects, for example, editing the login/authentication UI would require the wrapper to the authentication API, therefore, needing to pull 2 projects out of SVN.
Lastly, each folder within the projects will have the normal folder structure of trunk, tags, branches with the code under each specific one where necessary.
Instances is each environment in existence. For our setup we have a development, Quality Assurance, and Production. This folder "control" your deployment of your code, or in different phrases, this folder contains the code to be copied to each environment. The use of externals will give us the ability to not replicate the code within the repository. The uses of tags (or tagged versions) will give the ability to control what version exists in each environment.
Lastly, I will be touching on how we use this layout further as I get into how to use ColdBox and MXUnit while developing.
Please Note: This post is conjuction with a series of blog posts about my findings in setting up an enterprise development environment. Please view the rest of the posts at Coldfusion in an Enterprise Overview
This article is not going to go into how to setup version, or how to add an external to the repository tree. But how in concept to use SVN and an external to achieve application management.
First of course you need a SVN repository, which for the purpose of this article our repository will be noted as "/".
Second we need to know that will we still be using the concepts of trunk, tags, and branches, they just won't live in the root of the repository. The trunk is the current working copy of development, while the tag folder is to version releases (by tagging). Branches will be used when "new" development is going on and emergency coding is required on the existing code base before the new development will be completed.
Lastly, we need to understand what will be in the root of the repository. These folders are instances, projects, and vendors. Therefore, the SVN repository will look like
/
instances/
projects/
vendors/
Vendors is any code not developed by our developers. For example, jQuery would be in the vendor location, therefore giving us the ability to manage what version of jQuery is in each environment. Each folder under Vendor, for example jQuery, should have a trunk, tag, and branch folders.
Projects is each sub-application in our product and it is each supporting product. For example our enterprise has a central account management API, which is only accessible through web services, therefore, a wrapper for that API will be project. While the product that uses the wrapper to the api is also another project folder.
Another example describing the separate project methodology is a shopping cart application, you'll have the cart, sales tax calculator, shipping calculator, billing information, and the shopping cart application itself. The proposed use of this would have each of those in separate folders so different developers can work on different areas in a unit testing methodology.
With separating everything the need for one "project" for the actual application still exists. Right now this requires the developer to know the relationships when extracting projects out of SVN. If a developer is required to work on the actual application, the developer would need to extract all other projects, for example, editing the login/authentication UI would require the wrapper to the authentication API, therefore, needing to pull 2 projects out of SVN.
Lastly, each folder within the projects will have the normal folder structure of trunk, tags, branches with the code under each specific one where necessary.
Instances is each environment in existence. For our setup we have a development, Quality Assurance, and Production. This folder "control" your deployment of your code, or in different phrases, this folder contains the code to be copied to each environment. The use of externals will give us the ability to not replicate the code within the repository. The uses of tags (or tagged versions) will give the ability to control what version exists in each environment.
Lastly, I will be touching on how we use this layout further as I get into how to use ColdBox and MXUnit while developing.
Please Note: This post is conjuction with a series of blog posts about my findings in setting up an enterprise development environment. Please view the rest of the posts at Coldfusion in an Enterprise Overview
Comments
Post a Comment