CenterTrack 1.6.1.63 is ready for release

I am pleased to announce the release of CenterTrack version 1.6.1.63. This release contains some minor bug fixes and custom reports.  Please contact me directly if you wish to be upgraded. If your custom report is mentioned in the release notes, your upgrade will take priority and can be scheduled immediately. Please keep in mind that we cannot perform the upgrade without your permission.

We are now aggressively working on the 1.6.2 release, and hope to have that available to you shortly.

As always, if you have any questions at all, please don’t hesitate to call me.

Finishing out the release process…Quality Assurance testing

Finishing out the release process…. So, we’ve talked about the versioning, design, build and unit test phases of the release process… what’s left? Well, only the most important step in the process… Quality Assurance… or QA. The QA process is a step where we give the application to someone other than a developer to review and… in all honesty… try to break. While QA will follow the test steps defined during design and implementation, they will also push those buttons that should never get pushed. QAs job is to try to find all the bugs before the release goes out the door. Now, let me assure you that this is almost an impossible task. Look at Microsoft, for example… how many times do they release a new operating system and then a service pack follows almost immediately? That’s because, inevitably, as soon as QA gives it the stamp of approval and you put it on the first client’s machine, someone finds something that everyone missed. At Controltec, we have taken great steps to improve this QA process. We put the code, reports and database on a completely “neutral” server – one that doesn’t have any development environment or tools installed. We take a “clean” database – one that can’t be updated or modified by developers and we run through the upgrade process as if we were upgrading a client. This process tests the upgrade scripts to ensure that they will run on client machines without issue and then prepares the QA site for testing. Once the site is updated, QA can begin testing by running through test scripts and general “smoke tests”. Depending on the version of the build, regression testing is also performed. For instance, if the release is a patch that fixes 2 procedures, then a small bit of regression testing is done – add a new family, validate ADEs, etc. However, if the release is a full release, such as 1.6.2, then a full realm of regression testing is done throughout the entire system. We attempt to “touch” every page and every scenario. As we continue to strengthen our QA department and testing, these regression tests are being automated and new tests are continually added to enhance the test suite. Of course, if anything fails QA, then we push the release back down to development where the process starts over with the build, goes to unit testing and then back to QA again. We continue this cycle until everything passes and we have a valid release candidate. So, that’s QA… in a nutshell. It’s no easy task, let me assure you! As you can see, there is a lot involved in this process, which is why a lot of these releases take time to get out the door. As we speak, 1.6.2 is a handful of SPRs away from going to unit test… so it’s getting closer!

Release process, continued…Unit Testing

In this next installment of the Release Process blog, we are going to talk about unit testing. Unit testing is where we take each individual feature or “unit” and test it in a build candidate. This phase is important because it gets the code off of the developer’s local workstation and into a full build of the application. All of the parts are pulled from source control to get the very latest of all work (SPRs) and items for the release, and a candidate is built. The candidate is placed on a “neutral” machine (i.e. not a developer’s machine) so that it can be tested in something close to a real world scenario. We expect to find a lot of bugs or errors in the stage of the process as the build comes together. However, at this point, it is still the developer who coded the feature who is responsible for testing their unit. For every feature that passes their unit test, there are a couple that don’t pass. The features that don’t pass are investigated and resolved in preparation for another build candidate. The cycle continues until all of the units have passed unit testing. Also, during this process, test procedures are confirmed and updated in preparation for the candidates move to the next phase… Quality Assurance. This phase is also the last chance to fix any of those other pesky bugs or issues that have come up while the development cycle was occurring. For instance, if the state announces an 801a change we will often push a release back into unit testing to capture all of these changes for the end result. These push-backs are the main cause of release delays because this often means that not only is this release delayed, but the current version has to be updated, tested and released with the changes prior to this release continuing. Check back soon for details on this next phase as we get closer to the release.

801a – State Preschool Reporting

 There have been many changes to the 801a in the past month or so since the state added the new fields. We’ve noticed that their error checking has also changed and so we’ve modified the report accordingly. We are now getting reports that agencies are successfully uploading their reports to the state. However, one error that has been returned deserves some recognition. If you are getting an error about an invalid Need Reason and it applies to the preschool care you are providing, you may not be getting the “Q” reason you expect. The reason for this is that the system is checking for a specific flag in the programs in order to code something with a “Q”. So, if you are receiving an “I” along with an error code for your CSPP kids, here is how to resolve it. 1) Add the CSPP Program Flag. Log in as an administrator and use Edit Tables to add a Program Flag. Call it “Child enrolled in CSPP program”. 2) Select the program flag on the preschool program. Again in admin, use the Edit Programs tab and select the preschool (CSPP) program. Modify and add the flag added in step #1 3) Remove the old preschool flag. Note that the report will first look for an old flag with the text of “state preschool” or “handicap” prior to the “CSPP” flag. If it finds one of these, it will still code the child with an “I”. Remove this flag from any program or programs. With that, your “invalid need reason” errors should fall off of the report and next month will go even smoother.

The Build Process

In this installment of the release process blog, we are going to talk about the build process. 

 

For many of us here at Controltec, this is the fun part.  This is where we actually get to make the parts work.  The developer takes the design and test procedures and digs into the code to build the feature into the application.  In some cases, database tables or fields need to be added to the database, in some cases changes to an “rpt” file occurs and in some cases changes in the application occur.  In many cases, all three have to happen.

 

As an aside, an “rpt” is a report file.  RPT being the extension to a crystal report file which is the tool we use to create reports in CenterTrack.  For this reason, many developers will refer to every piece of paper that comes from CenterTrack as a “report”.  Every NOA, letter, listing, communication or item that is printed to the printer is done in a crystal report file coded into the application.

 

When all of the changes for a feature have been coded, the developer completes development testing on the changes made.  This is a very, very basic level of testing that occurs at the developer’s workstation with the developer’s environment.  This testing is meant to test that the feature has been coded and does not indicate that the feature is ready for release.  However, it does indicate that the developer believes it is ready and they can move onto other features in the release.

 

Once all of the features targeted for the release are updated and ready to build, the test version is built.  The actual build process consists of 2 different actions.  The first is “scripting” where a database script is completed to capture all of the database changes made since the last version.  The second action is the building of the application, including the latest report files.

 

When the test verson  is ready to go, we move into the next phase… unit testing.  Check back soon for this next phase in the release process!

Blog with me!

Now that we’ve had the blogs online for a while and have officially announced its existence, it’s time to get everyone involved.  If you have something that you would like to contribute to this blog, you can participate in a number of ways.

1) E-mail me and ask to be a contributor.  Contributors can then login to the site and post their own blog.  Controltec will review and publish it to the site for all to read and comment.

2) Comment on an existing blog.  You can start a discussion with other viewers on the site by clicking on the Comment link under each topic.  Make a comment or add a contribution/take to the discussion for everyone to review and respond – you can even add relevant questions to your comments.

3) E-mail a topic, question or request that you would like discussed in the blog.  I will review the topics received and create a new blog topic if appropriate.

Also, note the “Agencies” box to the right of the blog text.  We can add a link to your agency’s web site in this area so that other users can review and communicate with your agency through your agency web sites.

Help me make YOUR blog better… let me know what you want to talk about!

What is a build number?

There is another group of “hidden” numbers that you might often see or hear us refer to.  The last digit in the application is the “build” number.  Builds are used for internal testing and when a hotfix or patch needs to be released to fix the latest release.  Controltec has build numbers on the database and the web application code so that these patches can be installed without a major overhaul and effort.  Because great effort is made to keep enhancements out of these patch builds, Controltec can install a patch build quickly and easily at the agency without fear of breaking other parts of the system.

Version numbers, continued…

The first digit in the version what we call the “Generation” number.  These come along when there are major shifts in platforms or system cores that require a ground-up rebuild of the system.  CenterTrack is currently in its first generation (hence the 1 in the 1.6.2) and has been up and running since 2002.

What are version numbers?

Today, let’s discuss the version numbers…

CenterTrack currently has 2 different “released” versions of the system.  Almost all clients are on the 1.6 version of the application, with just a few stragglers (you know who you are  ) hanging onto the 1.5 version.  Controltec is currently working on the next “dot” release of CenterTrack (1.6.2).  These types of releases are often called a “dot” release as we refer to it as “dot 2”.  “Dot” releases are intended to introduce minorenhancements or new modules that do not affect the rest of the system’s integrity.  Major enhancements, or things that affect the entire system, are designated for a Major release (i.e. from 1.5 to 1.6).  For instance, 1.5 introduced major changes to the way we enter attendance and invoice for fees, and 1.6 introduced the new DRDP module. 

The upcoming “dot 2” release enhances the DRDP module in preparation for a future release cycle for the Head Start module.

801a changes for CenterTrack

As you are all probably aware, the state has released information regarding changes to the 801a report effective for the July submission that is due this month.  Controltec is currently implementing these changes in CenterTrack. We expect to have the release available very soon, and in time for your July due August report.  We will update everyone within the  week on the progress and approach for the July report.

If you have any specific questions regarding these changes, feel free to post them as a follow-up here so we can address them to the group instead of each individual client. 

Here’s the link to the state’s site regarding these changes: http://www.cde.ca.gov/sp/cd/ci/update12.asp