The stages of the lifecycle

This document describes the processes through which the developer maintains the lifecycle of the TGPRINT software product: how changes are planned, developed, tested and released, how defects found in operation are remedied, how the product is improved, what personnel is required and how technical support is provided. It complements the Functional characteristics (what the product does) and the User guide (how it is used). It is intended for client print shops, for those evaluating the product and for the developer's team.

The product is delivered as a service over the internet: a single current version, maintained by the developer, runs for all client print shops, each on its own instance. The lifecycle therefore has no "versions installed at the customer's site" that would have to be migrated one by one: a released update reaches all instances, and the processes below are the developer's. What falls to the client print shop is described in chapter 02.

1.1. The eight stages

1. Planning
2. Development
3. Testing
4. Demonstration and validation
5. Implementation and operation
6. Improvement of the product
7. Collection and remediation of defects
8. Decommissioning

Stages 1–5 are repeated for every released version; stages 6 and 7 run continuously, in parallel with operation, and feed the planning of subsequent versions; stage 8 concerns either an instance (a print shop that ceases to use the product) or a function withdrawn from the product.

1.2. Planning

The decision to create or to modify a function is taken on the basis of:

• the requests and observations of the client print shops, received through the support channels, at launch or from the dedicated manager;
• the experience of the developer's own operation: the developer is itself a print shop and uses the platform daily on real orders, so that a workflow problem is felt first in its own production;
• the evolution of the web-to-print market and of online commerce (payments, delivery, the expectations of end customers) and of competing offerings;
• changes in legislation and at external providers (VAT and invoicing, data protection, the interfaces of payment processors, of couriers and of email services), which take priority over improvements;
• security needs and the updating of the underlying components.

The result of planning is a development plan with priorities: defects that stop sales or the processing of orders take absolute precedence, followed by legal obligations and those of the providers, then by the improvements with the greatest usefulness for the greatest number of print shops. For each item, the effort, the risk and the impact on existing data are estimated.

1.3. Development

1. Detailed analysis of the change: what problem it solves, who is affected (end customer, manager, operator, accountant), which screens and which data change, how existing data remains valid — an old order must open and read the same way after the update.
2. Implementation in a development environment separate from production, on its own working branch of the code, under version control: every change has an author, a date and a description, and can be reverted.
3. Review of the change before it is integrated into the main branch: correctness, security, compatibility, readability.
4. Updating the documentation and the translations (Romanian, Russian, English) for any change visible in the interface, together with the code, not afterwards.

1.4. Testing

1. Automated tests, run on every change: the price calculation engine, the rules for artwork, the server-side validations, together with the static checking of types and of code style.
2. Manual functional testing in the development environment and in the demonstration store (fictitious data), on the supported browsers and on mobile devices.
3. Regression testing of the critical flows before release: catalogue → calculator → cart and artwork → checkout → payment in the processor's test mode → the order in the admin panel → statuses and notifications → documents.
4. Verification of data migrations on a copy of the data, whenever a change alters their structure or their meaning, with the rollback procedure prepared beforehand.

1.5. Demonstration and validation

Visible changes, and those requested by a print shop, are demonstrated before release in the demonstration store and admin panel (Live demo). Observations are gathered, after which a decision is taken: release, adjustment or abandonment. Where possible, the print shop that requested the function validates it on its own real case before the function reaches all users.

1.6. Implementation and operation

This stage has two sides.

Implementation at a new print shop (the launch) is assisted by the developer and included in all plans. The usual path takes two weeks: the contract and access to the admin panel, with a launch manager who stays alongside until the first order; the import of the catalogue and of the price formulas from the spreadsheets the print shop already uses, with their verification by the print shop; the design, the content and the move of the store onto the print shop's domain; test orders placed by the print shop's team, from payment through to delivery; the launch and the announcement to existing customers. The requirements for putting the product into service are listed in Functional characteristics, chapter 02.

The release of a new version into operation takes place without any action on the part of the users and without interrupting sales: the new version is built on the server while the current version continues to serve, the switchover occurs only after a successful build, and if the build fails the current version remains untouched. Large changes are released outside the stores' peak hours; urgent corrections, at any time. After a release, the key pages and flows are checked, the logs and metrics are watched during the first hours, and the store administrators are informed — as a rule before the release — whenever the way of working changes. The previous version remains available for rollback. The public documentation is updated together with the version; each chapter displays the date of its last update.

1.7. Improvement of the product

Improvement is carried out continuously, on the basis of the print shops' observations, of the developer's own operation and of the evolution of the market, according to the process described in chapter 04.

1.8. Collection and remediation of defects

Defects are discovered through monitoring and logs, through reports from the print shops and their customers and through the checks carried out after every release; they are classified by severity and remedied according to the process described in chapter 03.

1.9. Decommissioning

Cessation of use by a print shop. The subscription has no minimum term; at the print shop's request:

1. the date of cessation is confirmed and it is established which data is to be exported;
2. the data export is made available — customers, orders, products and files — in standard formats (CSV, Excel, PDF and the files as such), before access is stopped;
3. access to the site and to the admin panel is stopped; the domain belongs to the print shop and may be pointed by it to another site;
4. the instance and its data are deleted from the developer's systems after the retention period provided for in the privacy policy; documents subject to legal archiving obligations remain with the print shop, through the export at step 2.

The withdrawal of a function or of an integration from the product is carried out with prior notice to the store administrators, indicating the alternative and preserving historical data: old orders remain readable, with the values they had at the moment they were placed.

The discontinuation of the product as a whole, by decision of the developer, entails informing all users in advance, a sufficient period for exporting the data and assistance with the export; no instance is stopped without its data having been made available to the print shop.