Review: Aha

Aha demonstrates how a cloud apps works.  It is a requirement tracking software.  It has the integration to JIRA.

It manages the lifecycle before the requirements come to development in JIRA as a user story.



Releases are created for managing the target delivery for a specific deadline.  A release has a start date and an end date.
 https://support.aha.io/hc/en-us/articles/201226575

Releases are draw in a Gantt chart, called Releases Roadmap. The visualization using a Gantt chart is very powerful tool.  
https://support.aha.io/hc/en-us/articles/115001477463

Master Features are created as containers of user stories.
https://support.aha.io/hc/en-us/articles/115001477463

Master Features are added to Releases.  Or more specifically, User stories from master features are added to releases.  When you view the user stories, you can optionally view the major features of that release, before drilling into the details to view individual user stories.

Release Management

Release Planning

A list of features should be scheduled as part of the planning process.  In scrum method, each sprint is a release.  The release planning is handled as the sprint planning.
The features or fixes are prioritized.  They are documented as backlogs in the scrum system.

Release Notification

A list of customers may be waiting for a fix or a feature for a given release.  You will need to notify the customers that a release is available.

Documentation

The release note should mention what fixes and features are available.
The release note should be searchable.  A customer should be able to know what is the minimum required version for getting a specific fix or a feature.

Release Tracking on the Customer Site

For a given instance, you should be able to know the update history.  What is the version of the installation and what patches were applied.

It is particularly useful for the hosted environment.  The hosted customers should be able to submit the change requests.  Once the change is applied, the change history should be kept.  The change requests become the orders for DevOps.

When your software is solid, few customers may need or want to take an update.  The frequency can vary depending on the status of the product.

Modern Product Documentation

Here are requirements from user and product interaction perspectives:

• We should not require people to download docs from somewhere else.  Links to docs should be available within the product.  PDF is fine but context sensitive contents are better.
• Use videos to demonstrate How-Tos.  Again, links should be available within the product
• Show Release Note directly with the product
• Allow the users to directly enter a support case within the product
• Allow the users to provide suggestions directly from the product
• A small News&Update - directly communicate to your users

This is the modern software should be and I just saw one!!

Cloud Operator Acceptance Testing before deploying into cloud

The software package is developed in the dev env.  The dev env does not necessary reassemble the real production env.   It supposes to be a simple, isolated env for dev to code and perform unit testig.  That's why we need the QA env.  The QA env should cover the testing cases that represent the customer's deployments.

However, a cloud env may have additional requirements.

OpenSAML

To make an application as a service provider (SP), you need to support SAML protocol.

It includes accepting the SAML message and generate the SAML message.

This API seems help the developers to hanlde SAML

OpenSAML2 User Manual

Here are examples:

SAML Single Sign On Scenarios

There are two main categories of scenarios:

• SP-Initiated: A user attempts to access a protected resource from the service provider
• IdP-Initiated: A user logged on and access the IdP and then access a protected resource from the service provider.

The second case is the one I mentioned earlier as portal.
Here is a web site with a comprehensive list of scenarios.

SAML and SaaS

SAML is an important standard used in the SaaS world.

Scenario before SAML

Traditionally, the user and password need to be created in the service provider.
The cloud service provider need to maintain the users.

If a user leave the company, we no longer want the user to be able to access the cloud service.
The problem is that the administrator within the company may not be aware or may not have the visibility or the control over the user store in the cloud service.

Remember that the client company may use multiple services.  The IT administrator in the client company will need to keep track all the services that the user has access and figure out how to get the user out of the systems.

The IT administrator really wants to have one switch to turn off all the access.

The things become more complicate as the user may just change the job role, and the IT administrator may need to change the permissions granted to the user in each of the service the user has access to.

If the cloud service does not integrate with the client company's IT system, the entire system won't flow very well.

--

Understand Single SIgn On

Here are my notes.

1. The sign on process protects the software and the data stored within or accessible by the software. from unauthorized access.
2. The sign on process is to ask the user to provide something, such as password, to verify himself.  Only those people who have the right answer is allowed to get in
3. SSO, from user perspective, is about using the same sign on password and sessions for multiple applications.
• SSO allows the users to not remember multiple passwords.
• SSO can be used to avoid the user to provide the same thing over again (within a browser or even across browser)
4. SSO, technically speaking, is to by pass the login screen from the applications and use a login screen from the SSO server.
• Once the SSO is enabled, the application login page should not be seen by the users.
5. SSO allows the user information (password) used for authenticating the user to stored centrally, not in each apps.  The sensitive information can thus be protected.
6. However, applications can ask the SSO server to provide additional attributes about the users
7. The login page redirection from the apps to SSO server is a typically way to enable SSO.
• If the SSO server is also providing a portal service, in the other word, the applications are listed centrally, the redirection from an application URL may not be important.
• We cannot avoid the users to use a browser bookmark to access to the application.  Redirection from the apps to SSO is almost always required.  Also.  It may be from any page, not just the specific login page
8. Browser Cookie is a way to make the browser to "remember".  It is used to communicate between the SSO server and the apps. 

Here are notes about SAML:

SaaS vs Custom Sotfware Hosting

Software as a service means that you, as a client, do not need to install and deploy software.  You can just use your browser to access your application.  On premise deployment, on the other hand, means that you have to deal with installation, deployment, and customization yourselves. I recently learned a new type of software hosting service for on-premise deployments.

The service is exactly focusing on the pain point, dealing the customization of the software.  

Even for the software you deployed on premise, nowadays you can get the standard software from the software vendors online.  The installation and upgrade can be handled already via some automation.  However, the software package you get is still the standard software like everyone else has.

The new concept is that the customized software and configuration information are stored in the service provider.  You never really customize the software yourselves.  Instead, the service company provides the customized software for you.  The software you have is kind of a branch of the standard software and maintained by the service provider.  Also, the configuration files or metadata are deployed from the testing instance that the service hosted.  You are the client of the service provider and they maintain your software packages for you.  However, when it comes to deployment, you still have it in your facilities and still inside your firewall.

Health check

Heart beat report

Not just for human.

These are critical tools for ensuring the system up and running.