Best Practices for Deploying Configurations
Aptify offers the following best practice recommendations to project teams regarding the management of environments and migration of configurations between servers throughout the Software Development Life Cycle. The recommended approach is very similar to the method that the Aptify R&D staff uses in managing new functionality being added to releases of the core product. They are similar in the way that multiple developers are developing functionality in their individual development environment, which eventually must be integrated into a common server after a review and QA cycle.
Below is a set of general guidelines for migrating each particular type of configuration to a production server.
See Using the Entity Packing and Unpacking Wizards and Using the Data Packing and Unpacking Wizards for information on how to use the Entity Packer/Unpacker and the Data Packer/Unpacker wizards.
Migration Scenarios
The deployment estimates in the following table do not include estimates for the time required to properly test your configuration on both your source server prior to deployment and the target server after deployment.
System Area | Composition of Deliverable | Migration Recommendation | Deployment Estimate |
Entity | Project team has added some fields to a core Aptify entity or subtype to support an object or wizard. | Use the Entity Packer to install the entity with additional fields on the target server, or if a subtype, install its parent entity. Alternatively, once approved in a review cycle by an Aptify-oriented DBA, manually create the fields to the entity in the target environment. | Minutes per entity |
Entity | Project team has changed existing fields to a core Aptify entity or subtype to support an object or wizard, OR added or modified other entity attributes/properties. | Once approved in a review cycle by an Aptify-oriented DBA, manually update the fields or properties in the entity/subtype in the target environment. | <1 minute per field. |
Entity | Project team has added a subtype to a core Aptify top-level entity. | Use the Entity Packer to install the subtype entity on the target server. Note: This is done by packing the top-level entity. All changes to the existing entity should be made following the rules above prior to completing this step. | Minutes per subtype. |
Entity | Project team has developed some new entities (top-level and subtype) to support business functionality specific to the client. | Project team can use the Entity Packer to pack and unpack these entities on the target server. The entity packer will use the Data Packer functionality as part of the Entity Packer to also pull Process Pipelines and Form Templates associated with that entity without the project team needing to use the Data Packer specifically. | Minutes per entity. |
Object Repository | Project team has written an Entity Plug-In or other .NET assembly that was created for the purpose of enforcing client-specific business rules. | Project team should open Aptify pointing their Startup.exe.config or attributes.xml file to the Target environment; upload this new object into the object repository from the development environment. Any entity changes should be deployed using the above rules. | <1 minute per object. |
Object Repository | Project team modifies an existing Form Component, Process Component, Entity Bulk Operation Component, or Layout Control. | Upload the modified object to the Object Repository using a new name in a client-specific package. Then, update the metadata record for the specified component to point to the new version of the object. | < 1 minute per object. |
Business Logic | Project team has developed a Process Pipeline to solve a business workflow need on an existing Entity. | Project team will use the Data Packer for the migration. They ONLY need to select the one Process Pipeline they intend to move. The Data packer will use its own logic how to find all process components and steps and every piece of data required to run the Process Pipeline on the target server. Event Handlers are not moved to prevent automatic availability of a Process Flow upon deployment. If an Event Handler is not present on a target server that is used with that Process Pipeline, the Event handler can be manually created on the target server. But no other individual items need to be selected at pack time in order for a process pipeline to be migrated. | Minutes per Process Flow. |
Business Logic | Project team has developed an Entity Bulk Operation (EBO). | Project team should manually create the EBO in the target environment, copying and pasting with the Windows clipboard where re-keying would be cumbersome. | Minutes per EBO. |
Business Logic | Project team has developed only a new Database Object defined as a Stored Procedure, View, Function, or Trigger that is being used in conjunction with a wizard, object, or other existing entity. | Project team should open Aptify pointing their Startup.exe.config or attributes.xml file to the Target environment, and then create a new Database record, specifying the object name, type, and SQL code (copied and pasted from the source server for that object). | Minutes per Database Object. |
GUI | Project team has created or modified a Form Template for an entity, perhaps even developing a new Form Component object. | Project team will use the Data packer to pack ONLY the Form Templates that were configured. The Data Packer logic will recognize underlying dependent items such as Form Components and Form Template Parts. No other items need to be selected with the data packer to move these except selecting the Form Templates themselves. Entity changes should be modified using the above rules. | Minutes per Form Template. |
GUI | Project team has created new Dashboards for Applications. | Project team will use the Data Packer to pack ONLY the dashboards that were created. The Data Packer logic will recognize underlying dependent items such as Dashboard Parts and Dashboard Components. No other items need to be selected with the Data Packer to move these except selecting the Dashboards themselves. | Minutes per Dashboard. |
GUI | Project team has developed new Applications and attached various entities to these new Applications. | Project team should open Aptify, point it to the target server, and create the new Applications. Then, specify the Entities that should appear in that application on the Application's Entities tab. | Minutes per Application. |
Reports | Project team has developed new Crystal Reports, Word Templates, Message Templates or other file based objects aside from compiled VB objects. | Project team should open Aptify, point it to the target server, and upload the items into the Object Repository directly and then attach them to entities where necessary on the Entities records. | Minutes per report. |
Build Engineer
Aptify recommends that you establish a project role of a Build Engineer through the duration of the project and beyond. This is defined as a role, in that is only a portion of one staff member' project responsibilities. The primary benefits of having this role in play include:
- Introduces a quality controls step into the deployment process
- Creates full configuration documentation as to elements that have be implemented
- Ensures, through simple testing, the viability of all configurations
The responsibilities of this role include deployment of configurations and maintenance of deployment records. The following details the requirements:
- Understanding of Aptify Framework Administration, including:
- Use of the Entity tool and the Entity Packer / Un-packer
- Use of Data Packer / Un-packer
- Configuration of Process Flows and Form Templates
- Meticulous in execution of installation steps
- Thorough in logging all changes
- Demanding of strict adherence to deployment documentation requirements from developers
Time allocated to this role varies over the course of the project. In Aptify's experience, the peak workload is toward the end of the heaviest development phases. On average, over the course of a yearlong implementation, 1 day each week is likely to be required. During peak weeks, it is likely to consume most of the time for the individual responsible, with the balance of the weeks a much smaller time requirement, on the order of a few hours each week.
Once live, the time necessary for execution of this role is commensurate with the amount of development, which is done over time.
While the individual acting as build engineer will be subsequently involved in the application of service packs and upgrades, his or her involvement will be limited to an informational role and will not be responsible for ongoing application maintenance. Rather, the engineer's impact to the process is in his or her knowledge of the deployed configurations.
The build engineer's primary environments to manage will be the staging and production environments. Development environments are to be managed by the developers themselves. Their deployment to the master development environment will be according to the instructions they have created for the build engineer. This forces the developer to complete a cycle of unit testing against their deployment instructions, increasing the likelihood of accurate documentation.
Copyright © 2014-2017 Aptify - Confidential and Proprietary