Ever wonder how PUBLIQ applications are updated? Well, we’re sharing a little behind-the-scenes explanation of how our teams collaborate and strategize to create software releases. There are several steps involved in our process to ensure our local government and utility offices have the features and functionality needed to run efficiently and serve their communities with ease. Every release, no matter the size, is influenced by our customers. We listen to their ideas and constantly improve our products with their help.
To better understand the process, take a look at our three types of software builds:
- Service Pack: A large build of new features, typically for several products. These are typically released quarterly and grouped into two categories: Finance and Tax.
- Addendum: A smaller build that’s released between service packs that are identified with letters (e.g., 7.1.22a). These are common when a bug must be fixed for multiple customers or when a big change happens between service packs, such as IRS or tax changes.
- QSU: QSU stands for Quick Service Update. These are built when a customer, or group of customers, needs an update right away and can’t wait until a larger release. Think of these like patches that get you by until the next full release goes live.
At PUBLIQ, we use an agile software release process, meaning we plan incremental releases and break them down into several different sprints in order to get the work completed efficiently. In addition, one of our main priorities is ensuring all teams are up to date on the new features or changes of each release, so several meetings and demos are held throughout the process. Let’s dive in.
- When an enhancement or fix is identified, a story is written and added to our project management software. A story is a description of the feature to be developed or changed, written from the perspective of the user, and includes any functional details or images needed to understand the update.
- Stories are then added to the product backlog, which is a list of proposed new features and changes that is continuously updated.
- Our Development team focuses on grooming. They meet to look at the stories currently in the backlog and determine what resources are needed and how long it will take to complete them. Grooming meetings occur weekly.
- Next is planning, which occurs every two weeks. This two-week period is referred to as a sprint. At this point, the teams know the details of each story and use this time to define the work they will complete and in what order. The idea is to focus on and complete a specific set of stories during each sprint. Service pack releases often involve several sprints.
- During each sprint, Development works to code the changes into the software. Every morning, our Product Management, QA (Quality Assurance), and Development teams have standup meetings, where they provide updates on the status of their assigned work.
- At the end of each sprint, Development hosts demos to review the completed updates with our Product Management and Operations teams.
- Our QA team then focuses on regression testing. During regression, the application(s) is thoroughly tested to catch any new errors that may have been created due to the changes made. If an issue is caught, it’s fixed, and then tested again until no errors are detected, and the software runs as expected. This occurs for every sprint until all sprints are completed. For example, if there are four sprints for a service pack, all sprints are retested (like a recap) before the entire release build is tested to ensure every feature is correct in the build.
- Before any service packs or addenda are released, internal demos are held with Training, Client Services, Batch Operations, Sales, and Documentation teams to ensure they’re updated on the details of the new features.
- The Product Management team makes the final call as to when the complete release is sent to our “test customers,” which are customers who receive new releases first. If they encounter any errors, they notify us so our teams can fix them before the release is sent again.
- After the release has been vetted by the test group, it is sent to “limited live,” which is a small portion of our customer base.
- Lastly, the release goes live to all customers, and it’s time to update!
