Académique Documents
Professionnel Documents
Culture Documents
NOTE: The following process assumes you have the EME installed on your test and production
machines. If this is not the case, see The Ab Initio Environment.
1. Developers create a sandbox and check it into the DEV datastore. They work on the
project files in the sandbox, checking in and checking out their source files to build
features and fix bugs.
Finally, the development group asserts that a project is ready to be tested. The group tags the
project they want to be tested.
2. Developers get their projects ready for promotion to testing: they make sure the project
parameters are used correctly, the graphs are deployed, and dependency information is
current. See "Preparing a project for promotion".
3. You run air object save to create a portable-interchange-format file (or save file) of the
QA-ready version of the project. See "Saving a project".
4. You run air object load to load the interchange file of the QA-ready project to the TEST
datastore. See "Loading a save file into another datastore".
5. You validate the promoted project in the TEST datastore by performing a number of
safety checks (to catch as many promotion errors as possible and ensure that the
promotion process does not introduce errors into either the project being promoted or
projects that have previously been promoted). See "Validating the promotion".
6. The QA engineers check out the QA-ready version of the project to their sandboxes and
report bugs to Development.
7. The Development team fixes the bugs and checks the project into the DEV datastore.
8. You tag the project in the DEV datastore, save the incremental changes using air object
save -since, and update the TEST datastore using air object load. See "Saving
modifications to a project" and "Loading a save file into another datastore".
9. The Test group checks out the new version and begins a new round of testing to verify
the bug fixes. The Test group verifies the fixes.
10. Repeat Steps 7-9 until the Test group declares the project sound and deems a version
ready for Production.
11. You use air object save to create a save file of the production-ready project based on the
last tag.
12. You promote the production-ready project to the PROD datastore using air object load.
13. You validate the promotion.
14. The Production team checks out and runs the project. If bugs are found, the Development
team fixes them.
Prerequisites
It is essential that you read the following chapters to understand the concepts in this chapter:
"Sandbox parameters and other attributes"
"Managing versions"
"Dependency analysis"
3. VERSION CONTROL
For example, to see the list of files in the lesson project and the version of each:
air project files /Projects/lesson -versions \
-basedir /u/work/mysandbox
The output, excerpted here, might be as follows:
EME datastore
An EME datastore is a specific instance of the EME: the term denotes the specific EME storage
that you are currently connected to through the GDE.
Obviously, many such datastore instances can reside in an environment in which the EME has
been installed. But you can only be connected to one datastore at a time: this is determined by
your GDE's current EME datastore settings, reached through Project > EME Datastore Settings
in the GDE main menu (on the command line the connection is specified by the value of
AB_AIR_ROOT, or by specifying the -root argument to individual commands). You can change
this setting and use a different datastore, but you can use only one datastore at a time in the GDE.
Source control
From the application developer's perspective, the primary use of the EME datastore is as an area
in which Ab Initio files are kept under source control.
The next section describes what this involves.