INTRODUCTION SETTING ENV FOR EXECUTING A DEPLOYMENT
Wayfast applications are hosted on instances of SQL Server and IIS. Larger customers are housed in dedicated instances of SQL Server and IIS, while the remainder reside on shared instances of both. Wayfast maintains the segregation of customer data on shared instances via customer-specific SQL logins, databases and schemas. Customer website assets reside in customer-specific IIS websites and virtual directories tied to a customer-specific app pool and service account.
...
The Wayfast rendering engine translates the metadata into the web-based application our customers experience. The deployment process (outlined below) automates the configuration of IIS folders and .NET applications, and populates the customer’s SQL Server database. Consequently, Wayfast development and deployment involves creating and populating databases, upgrading them as development proceeds, and verifying that Wayfast has deployed customer’s application correctly.
WHO PERFORMS THE DEPLOYMENT?
Most projects are synchronized by developers with the permission of the project owner. Production customer deployments have the added requirement of coordination with the customer prior to deployment in order to mitigate the chance of breakage.
INITIATING PROJECT DEPLOYMENT
After activating your task in Wayfast and selecting a project, click the “Play” button on the menu bar. Then proceed to designate an action type and target (i.e., the customer schema).
...
Figure 2 Project Deployment Synchronization Page
SELECTING ACTION TYPE AND TARGET CUSTOMER
The table enumerates the deployment action types displayed in the “Type of Action” dropdown.
...
Last, we click the “start” button to trigger the synchronization process.
POSSIBLES ISSUES DURING SYNCHRONIZATION: ACTIVE TICKETS
Deployments do not complete for a host of reasons, most often because of active development tickets. For the deployment to proceed, all tickets must be closed or marked as pending.
Wayfast neither performs static analysis nor versioning but does capture a history of each change made. The platform likewise does not facilitate isolation of changes via code branching. It falls to developers to ensure stored procedure changes do not break downstream environments. The ramifications of the all-or-nothing nature of Wayfast development (on what constitutes a single code line) means that unless measures are taken outside of Wayfast to pause development while a feature is in QA, there exists no way to fix bugs in the same code version, retest that version and deploy that version.
HOW TO ROLL BACK IF SYNCHRONIZATION BREAKS
The steps taken to rectify a synchronization error depend on the nature and severity of what broke. Wayfast employs log shipping for database backups. Frequency varies from customer to customer. QA, being less reliant on specific data being present in the database, uses this approach to restore prior database versions. When data loss is acceptable a DB backup can be restored to go back to a previous version in a simple and easy way.
...
Type | Description | Rollback Consideration |
Transaction | The customer’s Wayfast data – e.g., invoice and usage data. | While synchronization affects the data model only, rollback resets the data to a prior state. |
Business | Read-only tables created and managed outside of the current Wayfast application – e.g., tables shared with other applications. | Data should be unaffected by the rollback. |
Master | Configuration and reference tables used by the application itself – e.g., state and country tables, postal codes, &c. | This data changes infrequently, such as when a new version of the application. |
Log | Data used to track Wayfast performance and feature utilization. | None |
Partitioned Data Considerations
While generally not part of database synchronization and rollback, partitioned tables – and specifically transaction tables – may need attention after a rollback. Wayfast performs periodic partitioning of rapidly growing tables by copying historical data into a growing array of tables joined together with a view. This manual portioning (contrasted with SQL Server’s automated approach to partitioning) happens periodically, controlled by Wayfast. Even when a partition occurs after backup, the restored view should retrieve the same data as before. Any new tables and resituated data resulting from the partition will be absent from the view. The data itself will be in the original transaction tables and these may need attention to avoid the loss of recent data.
SYNCREPORT AND SYNCHRONIZACTION DETAILS
The Wayfast platform Syncreport details the performance and outcome of synchronizations performed across the Wayfast platform. You can access this report via the platform menu in the upper righthand corner of the Wayfast screen.
...
Finally, Syncreport provides links to download the SQL scripts that ran during synchronization.
ACHIEVING MULTITENANCY THROUGH SCHEMA NAMING
...
Figure 7 Project General Options
...
In future, Wayfast will support project branching and versioning whereas today it does not.
...
WAYFAST SECURITY MODEL
Wayfast uses customer-specific database user accounts and schemas to achieve data segregation and security. Thus, CustomerY will have its own user and schema, CustomerX will have its own user and schema, CustomerY will have its own user and schema, and so on. Each user has access only to that customer’s schema and each schema is designated as the default in the customer’s Wayfast database. Customers cannot access the dbo schema.
...