One of the very first tasks you should do in any software project, even before you write a single line of code, is to install a source code repository. This is where the development team keeps all of its code in a centralized location, using version control software to track and manage changes to files over time.
Version control systems are appealing to developers because they back up source code and keep track of changes. So when a new code version introduces a bug, it's easy to compare with earlier versions using text differencing tools to highlight what's changed and identify the problem.
Managers like version control systems because it helps prevent loss of data, and provides tagging capabilities for releases making it very easy to check a production version for error correction without disrupting the current development version.
I'll be discussing Subversion (http://subversion.apache.org/) in this book, so if you're already using another version control system, the same principles apply, although the solution might be a little different.
Subversion (SVN) has rapidly become the de facto standard free/open source version control system today. Binary versions of SVN are available for all major operation systems. Installation of the SVN server is very much dependent on the operating system, so refer to the installation instructions for your operating system.
VisualSVN Server (http://visualsvn.com/server/) is an excellent free solution for the Windows systems, and with a one-click installation, you really can't get an any simpler setup. There are a number of third-party clients available; TortoiseSVN is a popular choice on Windows, as it is integrated directly into Windows Explorer.
For batch programming, you will need to use a SVN command-line client, such as CollabNets' version (http://www.open.collab.net/downloads/subversion/). Subversion's integrations into various IDEs are also common, including JDeveloper, SQL Developer, TOAD, and Apanta.
 |
The previous screenshot shows the VisualSVN Server, containing a single repository named apex-solutions, with two projects named jquery and playpen respectively. The playpen project is used for this book, and contains a standard recommended layout: the trunk directory to hold the "main line" of development, a branches directory to contain branch copies, and a tags directory to contain tag copies.
The question of what to store in SVN is also partly answered in the screenshot we just saw. The short and simple answer is "everything to do with the project". You can use the example of a new developer starting on the project as a litmus test. Given a virgin machine, they should be able to do a single checkout, and be able to do a full build of the system. You may make exceptions for things that are large, or complicated to install and stable, for example, the database and IDE tools, such as JDeveloper or SQL Developer.
Here is a basic list of some of the types of files you would typically want to store in your code repository for an Oracle APEX application:
Database object scripts: Everything you use to define your application in the database. This includes a current Oracle Initialization Parameter (
init.ora) file, scripts to create your users, tables, views, packages, procedures, functions, and so on. If your application isn't too large, you could also include database schema exports to ensure you include absolutely everything.APEX application and related files: You can export and import your application definitions, including workspace users, application, CSS, images, files, themes, and user interface defaults stored in Oracle APEX. These exports provide a complete snapshot of your APEX application, allowing you to deploy it to another environment, or restore your application to an earlier state. The export files also allow you to recover individual components.
Web server assets: Your Ext JS files, application JavaScript, CSS, images, and so on, and all configuration files for your web server.
Documentation: Project management documentation, as well as the user help and administration documentation.
Utilities and command scripts: This is a catch-all for scripts that don't fit into any of the previous categories. Examples include scripts used to export and import the application, to stop and start processes, FTP files to web servers, deploying the application to other environments, and so on.