Our procedures are so refined that we are able to bring a complex new development onto a live system and test it there, so that we are ultimately visible to the customer switch to the "new version" at the push of a button
All customers receive an overview of all installed updates including graphically displayed time histories via the BACKEND. In addition, numerous metrics for the respective Live System are visualized.
Why are UPDATES vital?
The viewing habits through mobile surfing on smartphones and tablets have changed exponentially in recent years! The technical requirements are also constantly growing and changing, e.g. due to new web browsers on PCs and mobile devices, changed search engine specifications and current security requirements.
Modernization is a continuous process, which technically means that the backbone of the software (the technology base, the framework) must be continuously improved and further developed. A background noise of updates, which is financed by the monthly update lump sum.
As an operator, a successful platform will be continually expanded and improved in order to maintain or improve the high level of customer orientation, individualisation and comfort.
On the one hand you will want to adapt them to modern viewing habits (e.g. autocompletion makes suggestions, optical redesign), on the other hand you will learn in dialogue with your customers and improve things or add functions.
Project development takes place technically in stages of sub-projects.
From a technical point of view, modernization and project development are interlinked because the project functions are based on central functions or are interlinked with them. Both development processes must therefore interact continuously.
What does release management mean?
Working with "Release Management" is familiar from many ERP systems and their major providers.
One release per month or quarter is announced and installed via a complex upgrade, including subsequent troubleshooting.
This approach has led many people to the conclusion that ERP systems are "insanely complex" and "much more complex than web systems" - which is technically not the case, because a modern web trading platform can compete with an ERP system in terms of software space or complexity.
One applicant once put it this way:
When a release is changed, problems are created and then heroically solved.
We don't like this approach at all!
How we work
The software features are continuously (daily, weekly) installed on the live systems.
Per month we transfer approx. 600 software features to each staging or live system.
In order to achieve time-critical goals in a customer project, a further development of central areas is often required at the same time. These central changes are carried out and released in coordination with the quality management team just as promptly as the function updates of the customer project. The project teams and the quality management team work hand in hand.
We are able to make agile changes, extensions and further developments and bring them to the live systems in a timely and error-free manner. Thus the systems are very up-to-date, so that future development steps or prompt changes become much easier possible. The work for the software engineers becomes more pleasant, the efficiency increases significantly.
We constantly create a large number of updates ("software features"), which together represent the further development of the overall system and the respective customer project; software features are comparable to the transport orders of SAP software development..
We make this procedure possible by
the human factor
Quality as a living example
Experienced, quality-conscious employees (10-15 years in the team)
Interdisciplinary team, consisting exclusively of academics - computer scientists, mathematicians and engineers
continuous internal training
Actively integrated quality management team
Thematic specialist teams
Efficient cooperation through good team communication
the technology factor
- smart practices
- Development branches switchable as central branch
- Automated and manual software features possible
- Routinely roll out non-downward compatible changes
- Enable complex migrations through live branches
- Automatic test procedures
- Automated integrity testing
- Continuous software operation on the development system via selenium-based system
- multidimensional quality measures
- Organized and documented "Hey-Joe" support for specialists
- Internal monitoring and timely intervention
- Extensive training of new employees
- Continuous further development of joint process models
- Continuous further development of the tools
- specialized ticket and workflow system
- Customers and developers work on the same ticket platform
- High integration of the development tools with the ticket system
- powerful development tools
- Own tools for data synchronisation
- Own metamodel for database modeling
- Eclipse with specialized tool integrations
No procedure (Release Management vs. Continuous Delivery) can guarantee 100% error-free software. A very low error rate can only be further reduced by considerable additional effort, e.g. through multi-stage staging systems and very time-consuming testing.
This, in turn, is bought at the expense of disproportionately high costs and time as well as significant losses in agility. A Mars mission is extremely expensive and extremely unspontaneous.
We are of the opinion
- that agile development at the highest quality level (i.e. with a very low error rate) is the best basis for a sustainably successful platform.
- Our credo is: Avoid mistakes as a matter of principle. Correcting errors quickly and effectively.
- For years, we have been continuously striving for perfection, which is reflected in a remarkably low error rate.
- that this is also optimal for the total cost accounting of the customers
From this point the relevant question is:
There are extremely extensive project enhancements that are created with a team of developers over many months as a whole, and make very extensive changes. Such enormous project steps typically have to be brought to a live system via a complex migration.
Our goal over many years was to keep the shutdown time of the live system even shorter during a complex migration.
Developing a platform is like building a new plane in a hangar. No passengers, no environmental hazards, no stress. Now imagine that this airplane then climbs into the air and is never allowed to land again. The refuelling and repairs must take place in the air!
That is exactly what we do every day. 365 days a year. Sometimes also 366 days - maintenance, refuelling, repairs and extensions take place in the air, while you as captain fly and take your customers (= passengers) with you - without you noticing us!
Of course, we could stop the plane. But this is accompanied by losses for you: Google does not find your pages any more, your customers are annoyed if they want to order right now. And what if the platform goes online again, but the shopping baskets are empty again due to the repairs (the restart)?