It's not required to create a Model directory in your Module, but it gets its own section because most Modules contain one. That's where the majority of your functionality will be in most Modules that you write. We'll create a Model directory and then create a Model, and a Model Factory. So, create a directory called Model. In it, create a file named TestModule.php. We are going to create one factory Model (This uses System Detection or your own logic to choose a compatible Functional Model) and one Functional Model. Your real world Modules will contain multiple functional models, for different Architectures and Operating Systems.
So, the concept of an Autopilot file is pretty simple – a set of steps describing the Automation of one or many bits of functionality from your application.
Autopilot files are central to building automation with Pharaoh Tools.
Autopilot files are the end product we want from configuring our automation, as these are to become the scripts that control your applications execution. You can define inputs for your Module parameters on the fly as methods within your scripts. Each step relates to a module, and will execute in sequence.
The recommended format for an autopilot file is not the format shown, its the Pharaoh DSL. The DSL file's are parsed by the AutopilotDSL module, and they will be silently turned into an array following the below structure. When you call the Autopilot command at the command line, it requires being called with a parameter --autopilot-file . If the file you specify here has an extension of ".dsl.php", it will attempt to load the file as a DSL. If you specify a file extension of ".php",
Here's a simple example:
Your Virtufile is where you will store the Hardware, Network and Provisioning Configuration for your Virtual machine. Pharaoh Virtualize will use a set of steps describing the Automation of one or many bits of functionality from your application.
So, the concept of Boxifying your Pharoah Project is pretty simple – store the connection details for each box in each environment into the project settings file.
Now that we know which boxes will be doing what, we can create some Operating System and Software Package configurations for those boxes, so they can do their job. Here's where we get some more of our convention over configuration goodness, as we'll get default Infrastructure templates.
Now that we have our boxes all set up nicely to store, host, build and deploy our app, lets prepare it so that we can perform any of the deploys that happen throughout the stack with a single command. Here's where we get some more of our convention over configuration goodness, as we'll get default Infrastructure templates.
Now that we have our app deploying to any environment with a single command, we want a nice smooth build set up so thatwe dont even need to perform our deploy command. After this step, we'll have a reasonably Continuous Delivery setup configured.
To begin I should probably highlight that we are currently still in a Beta state. We have quite a few bits of code to refactor, some parformance enhancement, and a fair few @todos. We're cracking through them and velocity on this will increase quite a lot after our official launch – So, beware of bits changing for the better quite often. As a general outline, when developing a module we would recommend that you find one which already does somehting similar to what you're trying to achieve, copy it, perform some file name changes (as specified in File Structure Notes) and Search/Replaces so that it has your new name and is compatible, which will save you some time.
Now we have our Module, we'll begin by creating an Info file for it. This file contains information about the module, including routing information. Create a file called info.TestModule.php in your TestModule directory. This version of the file contains comments explaining the use of each method or property in contains, so you can see how they're used. Your file should look like the following:
The settings file for a Pharoah project is called papyrusfile, and it is stored in the project root. It is a file containing only a serialized PHP array of settings manipulated through the EnvironmentConfig Module.
The Templating Module is one of the most common dependencies. It's used to install files on a system (usually configuration files) with pre-defined parts of the file being defined dynamically at runtime. PTConfigure includes a BaseTemplater that you can extend in your own Modules, so that you can easily create a Module yourself for modifying a configuration file. An example is the Templating Module used in the ApacheConf Module of PTConfigure.
So, lets start with creating a directory in the Extensions directory. In keeping with our Modular design pattern, this directory should contain all the code required for it to work (not in any other directories) except for functionality in other Modules which are required as dependencies. Also, removal of this Module should not affect any other Modules, unless they specify this as a dependency. All Pharoah Module names are CamelCase so we'll begin by naming our module directory TestModule.