Release software in Cloud, Desktop and Enterprises
There are different production environment types when it comes to release software:
Read the Article on Medium published in the Serious Scrum publication
- Cloud applications like Gmail, that have their production environments in the cloud and are not installed on customer premises
- Desktop applications like Libre Office that are installed on the end customer physical machine
- Enterprise software products like SAP that are released in modules by SAP SE and later need to be customized to adapt to the customer needs
Release software in Cloud
In cloud-native platforms, everything is under the control of the organization that owns the product. If an update is done to the software in the cloud, it can be automatically distributed to all the end-users. Most of the time, the update for the end-user is seamless and easy as refreshing a browser page. This is a case where all the advantages of DevOps are pushed to the extreme. Every time that a feature is ready to be released it can go from the development environment directly to production with a push of a button.
All the automated pipelines will do the checks for code quality, performances, regressions, and in case all the quality gates pass the software can go directly into production, and the end-user can benefit from the software update. This is also the scenario where you can stretch to the extreme benefit from the fast feedback from end-users. Just release a minimum viable product and build additional features based on user feedback.
In this case, we don’t wait until the end of the Sprint to do the release. While keeping the Scrum events planned in each Sprint, the software release can be just another point in the Definition Of Done. So that the implemented functionality will be considered Done when released and not when it is ready for release. The Sprint review can be done, as usual, at the end of the Sprint. In the Sprint review will be discussed all the Backlog Items Done during the Sprint and the value that they add to the released product.
Release software for Desktops
Everyday we use desktop applications for various tasks. From document editing to video, image editing. What do you usually do to get such kind of application? You surf the internet, find an application that may suit your needs and you download it and install it on your laptop. Usually, in this case, the application updates are less frequent than the updates done for cloud applications for several reasons, from package distribution that can overload the distribution servers, to package creation and test, that can take some time. Of course also, in this case, it is good to adopt DevOps and Scrum to gather fast feedback from the end-users about new functionalities but most of the time is not feasible to deliver new features more than once per day as it may happen for cloud applications.
In this case, the production environment is the user laptop and the production software is the package that is distributed to the end-users. While on cloud platforms the organization that owns the software owns also the production environments, in the desktop applications case, the production environment is the end-user laptop. It will not be possible to collect real-time metrics to put them in the implementation feedback loop. With the end-user authorization, it will be possible to collect usage reports and information when a crash in the application happens but not more than that.
In this case, the releases can happen after multiple Sprints. However, it is crucial to have a releasable product after each Sprint, the release may not always happen at the end of the Sprint.
Enterprise Software in-house product
When an enterprise installs software developed in-house on private clouds or customer premises, most of the time the software needs to be customized according to customer business needs. In this case, there will be different organizations working on the software:
- Product Development Unit
- Customer Unit
In this case, the Product Development Unit releases the product to be customized and the Customer Unit has the responsibility to implement and configure the product for specific customer needs. It may not always be possible to stay up to date with the latest Product release with the current system integration implementation.
When the product is developed in-house, there could be the possibility to access the Customer servers directly from the Product Development Unit environments. In this case, it is possible to roll out patches for the product directly when they are released. When a new patch on the product is created, for security reasons ar for bug resolution, it is possible to do the automatic rollout for all the customers that use the product.
So, in this case, two DevOps streams can be identified:
- From the Product Development Unit to the Customer Production Environments
- From the Customer Unit to the Customer Production Environments.
The question here is: is it a good idea to have 2 parallel streams that release on the same production environments?
These parallel streams if not coordinated in the right manner can conflict and try to do simultaneous installations in the same environment. So, also in the case that the Product Development Unit and the Customer Unit, both have access to the Customer production environments, it is still desirable that the Customer Unit always has control over everything that happens in the Customer production environments.
Release software in Enterprises
In this case, the release can be done at the end of each Sprint or after a couple of Sprints, to agree with the customer on the release cadence. If the product is business-critical for the customer, it is needed to agree on the release timing to plan, if needed, the day and time that the system will be unavailable because of the update. Of course, it is needed to release during the Sprint when a production bug has to be fixed.
However there is no real rule of thumb here, and it depends on the product and product area that we are working on. Companies that use Scaled Agile prefer to have the release of new functionalities each couple of Sprints while bug fixes should be done As Soon As Possible (ASAP). It’s very frequent to receive emails with the statement, to be done ASAP, which adds a lot of pressure on the team. Of course, it is a task of the Product Owner to mitigate these situations and correctly prioritize this kind of request that can be counterproductive for mood and quality.
Final Thoughts
In all the cases it is good to adopt Scrum and DevOps to the extent that the application type allows. It is always a good idea to have small product increments to gather fast feedback from the end customer. Scrum and DevOps are born for that.
Always stretch to the maximum the benefits that come from collaboration at all levels, from the Development Team to the Customer, is a must to create successful products.
Thank you for reading!!!
If you liked the article you can read more in the Agile section