Dieser Artikel ist auch auf Deutsch verfügbar: FAQ zu FirstSpirit Release-Management
e-Spirit develops software on the basis of a continuous improvement process. The aim is to develop functions in an agile and needs-based manner, to make them available to customers more quickly, and to continue elevating the quality of the software. This means that:
- New features and extensions are released immediately after development, testing, and documentation – irrespective of the version number.
- Wherever possible, large extensions are rolled out incrementally – even if a feature has not yet achieved its full intended range of functions, an initial version is released as soon as it provides a useful additional benefit (minimum viable product). Additional features and convenience functions are then gradually added in the following releases.
- There are no more big-bang releases. Releasing features immediately allows the software development output to be distributed evenly over time.
This approach affects our usual handling of FirstSpirit version updates and involves new best practices.
When can we expect the next FirstSpirit version and what is it called?
e-Spirit has been releasing new FirstSpirit versions on a more or less monthly basis since 2016. This pace will continue. All releases are generally equivalent; there is no longer a functional distinction between "Maintenance", "Release", "Minor", and "Major". The consistent use of agile, incremental processes and the effects this has on the functional scope of the software can be seen as an even staircase structure:
Every update comprises new features and fixes which are explained in detail via the release notes. As a result, every bug fix update also generally includes an improved functional scope of the software.
In the future, version numbers will only play a technical role, for example during communication between customers, partners, and Technical Support. The announcement of new versions is no longer relevant for external communications or sales – features are now the main focus instead.
Until mid 2018, the (technical) version number will be updated as per the existing model. In other words, the "R" number is increased with every release – "5.2R9" increases to "5.2R10", etc., Beginning June 2018, FirstSpirit releases will be named in the pattern <YYYY>-<MM>, e.g. FirstSpirit 2018-06. A (major) version number 6 will not be assigned.
Which approach does e-Spirit recommend to customers for updates?
e-Spirit always recommends installing every FirstSpirit update in order to benefit from the software’s best possible functional performance. Bug fixes are also always rolled out in the latest software release. We test every release for compatibility with the former version, meaning extensive manual tests are not generally required. Installing every update is not mandatory, but skipping several versions leads to a noticeably large difference between the software versions, which increases the likelihood that the update will have an effect on operation or use. Planned updates should not be postponed in anticipation of a major version.
How does e-Spirit support short update cycles?
An important objective for e-Spirit when it comes to software development is to prevent incompatibilities and migration work, or to compensate for these issues with the software. FirstSpirit updates should generally require little effort or be fully automated. Numerous software mechanisms (such as automated downloads and updates, API for automated roll-out, VCS connection, etc.) support developers on a technical level. Furthermore, e-Spirit utilizes its expertise and best practices to implement short update cycles.
Several safety nets within the software minimize the risk of side effects caused by updates. Alongside the manual quality assurance, we can also rely on high automated testing coverage during development. Should a release still cause unwanted behavior within the software, Feature Toggles (see below) can be used in many cases after an update to selectively reactivate the former behavior until a solution is provided through a subsequent release.
How will incompatible software changes be managed in the future?
In the past, announcing and rolling out incompatible changes was rare and tied to minor or major versions. As these mechanisms are no longer used, a timebox concept will apply in the future whereby all such changes will be announced through the release notes at least six months in advance. As before, old and new functions can be used in parallel during a transition period in order to enable a smooth transition.
What is changing for users of FirstSpirit 4.x?
Serious bugs in the software will still be fixed within the scope of maintenance for the outdated version 4.2. However, no new updates will be rolled out to make FirstSpirit 4.2 compatible with current Java versions, databases, operating systems, or other third-party systems. For example, FirstSpirit 4.2R4 is designed for Java 6, but this Java version is no longer updated by the provider and the (billable) Extended Support will also run out within the foreseeable future, meaning that secure 4.2 operation is not permanently guaranteed. Product enhancements (such as Content as a Service) will also not be provided for the 4.2 series.
e-Spirit strongly recommends updating 4.2 installations to the newest FirstSpirit version. The sooner an update is carried out, the better. For the time being, we have extended the maintenance service for FirstSpirit beyond the planned end-of life (June 2017). We reserve the right to discontinue the maintenance service at any time.
Is there a beta phase for the next FirstSpirit version?
Due to the incremental continuous development within a software development strand (trunk-based development), it is generally not possible to use a beta version or a DEV build. We recommend always using the newest FirstSpirit version so you can test and benefit from all the features and, as an example, develop your own FS modules. In some instances, new functions are made available to potential customers as part of a ramp-up phase before general availability so they can gather experiences in real scenarios together with e-Spirit. For example, during the introduction of FirstSpirit CaaS and for distributed development, we worked closely together with pilot customers to test the live operation of the products and optimize the ongoing developments, thereby achieving a high level of market maturity for the launch.
How are Feature Toggles implemented?
Feature Toggles (FTs, also known as Feature Switches) aid risk protection in software changes within existing projects. Server administrators can use them to control and configure new and old software behaviors during a transition phase. In the process, FTs go through a defined life cycle:
- e-Spirit implements a change of the software behavior or a new feature. The new behavior is secured via an FT if, for example, effects on ongoing projects are foreseeable or a function has not yet gone through sufficient testing. This may include internal refactoring or new features, but not cosmetic corrections or documentation changes. An additional factor is risk estimation. Based on historical data, we can estimate the likelihood of side effects caused by changes (bug prediction).
- In some cases, a feature may not yet have reached the status of general availability, but may be needed for selective testing or usage by individual users (ramp-up). Such changes/extensions can be launched using FTs. The respective function is already present in the FirstSpirit codebase but deactivated as standard by setting the FT to FALSE. Individual users can test the behavior by switching the toggle setting. e-Spirit then uses the feedback received by users to evaluate whether the new behavior is fully developed and/or if side effects emerge.
- In other cases, the FT is set to TRUE in a new FS version. All FirstSpirit users utilize the new behavior after an update as standard. If unwanted side effects arise in individual cases, the old behavior can be restored selectively, generally preventing the need for a server downgrade. Feedback from customers allows e-Spirit to correct the behavior in new releases until side effects no longer arise.
- At the end of the life cycle, the FT as well as old parts of the FS codebase are permanently removed from the software, thus cementing the new behavior. Before the relevant update, it must be ensured that the ongoing project displays the expected behavior when the FT is removed (or with the FT set to TRUE). The FTs used can be evaluated by administrators at any time using the FirstSpirit error reporting.
Using this model, FTs cannot be used to permanently configure software features. FTs are an additional security net and not part of the release of the FirstSpirit functional scope, and thus also not documented in the ODFS. Incorrect use or invalid configurations of FTs could have a negative impact on the performance or behavior of the software. For this reason, FTs should only be configured following a consultation with e-Spirit Technical Support, who then informs customers, partners, and project managers about when and how to properly implement the FTs. This ensures that feedback from ongoing projects flows directly into our product development and administrators are notified about the discontinuation of used FTs in good time.