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:
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:
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.