Eptura Workplace Release Management

Eptura Workplace is an evergreen solution with updates occurring as frequently as weekly and customers always being on the latest version. Version control is strictly enforced as part of the software development lifecycle with segregation between test and production environments. Once test changes/modifications have been thoroughly tested, then they are scheduled for going live on production. Eptura Workplace uses Github to handle application version control. All upgrades are automatic and no action is required on the part of the customer outside of learning to use the new features as they become available.

As an evergreen solution, Eptura Workplace has the flexibility to apply or roll back changes to keep the production version of the solution working at optimum efficiency. To allow for testing of changes prior to release to the production environment, Eptura Workplace also maintains two pre-production environments (preprod and preprod2). These two environments, which only receive changes after the Software Development Lifecycle (SDLC) is completed, allow us to validate upcoming new changes prior to release to general production. 

Eptura Workplace uses the Software Development Lifecycle (SDLC) to develop and apply application upgrades and patches in a formal, consistent manner. Version control is enforced at each stage of the process, with segregation between test and production environments. Refer to the following list of highlights of the SDLC:

• Design: based on customer “wish lists” or feedback, internal requirements, and identified shared needs.
• Development: based on approval by senior management.
• Testing: All updates are thoroughly tested.
• Release Management: code is checked in and deployed, and can be rolled back quickly if needed.

The first thing to note is that all changes are implemented in a manual fashion. Each change tracked from start to finish using our internal ticketing system, and changes only move to the next step as the ticket is updated by authorized personnel. After the developer has sufficiently tested and reviewed their change, the ticket is placed in the quality assurance (QA) queue, where it is prioritized for testing based on ticket type and impact. QA teams use staging environments for initial testing, where user acceptance testing (UAT) can be performed by both internal QA teams and using third-party testers (Rainforest QA). Automated tools such as Siege are also used during this stage to simulate a large number of simultaneous users and ensure performance benchmarks are met.

After the application changes are thoroughly tested by QA to verify proper performance, the new code undergoes a code review to ensure internally-defined best practices are followed and any OWASP-identified security threats are remediated prior to the ticket being approved for pre-production. Any issues found result in the ticket being returned to the developer to address the issues prior to resubmission.

Tickets that pass the code review process are released to pre-production environments for site piloting and production mimicking. At this stage, a third-party dynamic security scan is performed to identify any OWASP findings that may have been missed during the manual security code review. Any findings are prioritized based on severity and remediated using the SDLC. If necessary, the ticket may be rolled back until the issue can be fully resolved.

Lastly, after a ticket passes all the above steps and is proven stable on pre-production environments, the ticket is considered completed and is authorized for release to the production environment. All approved tickets on pre-production are scheduled to be merged during the next production build, which is typically performed on a weekly basis.