Checklist post application development (JAVA)


Over my years as a dev, I've put together a checklist of things to dig into after i would be done with my application.

So for example, i build an app, i test it locally, i deploy it to dev env and test there, then qa takes it put its to qa / uat and eventually prod but sometimes along the way there are hiccups in config misses and etc.

So my question is, does anyone know of a good source where there's essentially a checklist for developers to be aware of to check AFTER they have just finished coding their app and are ready to release it? This could include stuff like "is it configured to run in all environments?" , "are the jms / topics set up in all envs", "if the app downloads some file, what if the file doesnt arrive or what if the file is too big or etc"...but more generic..

Any ideas? Some best practices as well possibly.
Who is Participating?
Gary PattersonConnect With a Mentor VP Technology / Senior Consultant Commented:
I disagree with Doug and zzynx.

This is not QA.  This is change management, and the document you describe is an implementation plan.  

I'm a consultant, and I've worked as a developer, tester, QA manager, project manager, DBA, sysadmin, network admin, security admin, operations analyst, and other roles over the years.  

Some of these places were very good at change management, and some were very, very bad.

The larger the environment, the more complex (and risky) implementations become.  I think it is a good idea to start with the most complex cases - large-scale application cross-platform development in a sensitive environment (military, medicine, financial services), and then work backwards to adapt the best practices found in those environments to smaller, less sensitive applications and environments.

In small shops, I've seen development, QA, implementation, and post-implementation all handled by a single developer.  Projects tend to be relatively small, and since all the responsibility for getting the application into production falls to one individual, these deployments usually go pretty well (or the developer doesn't last long...).  Good small-shop developers carefully document what they change in development, and make sure each required change is applied to production.  

I can certainly see how a general checklist would be handy in this environment.

For large implementations, a basic implementation plan document template (or group of templates from different teams) is often used - and that document contains sections used as a "checklist" for each group involved in a deployment.

Smart organizations update these implementation plan templates based on "lessons learned" from previous problems.

In larger organizations, implementation plan development responsibilities are often spread out over a much larger group - and implementations are often very, very complex.  For example each development team involved is responsible for generating the initial implementation plan by capturing every change made in the development environment into the implementation plan document.  

The implementation plan may be "owned" by the dev teams, a project manager, an implementation manager, etc.

In large environments, other teams are also often involved in developing and approving the implementation plan: security, network, capacity, database, system administrators for various related systems, infrastructure, operations, etc.  

As the project transitions into QA, the QA teams involved are also responsible for updating the implementation plan with any deficiencies discovered, or changes required during the QA processes.

Eventually, all of the teams involved, plus teams like change management, operations, and production support that have to deal with the application in production all must  review, update, and ultimately approve the implementation plan - taking into consideration common issues and concerns from previous implementations of this application or other similar applications.  

This is also a good point in the project for one last (automated if possible) comparison of the dev/QA/prod environments to verify that no required implementation steps have been omitted.

As a developer, I know that when something goes wrong, it often falls to me to fix it - or at least to identify where the problem is and engage the appropriate resources to get it fixed - regardless of the location or cause of the problem.

The best way to do that is to assume a lot of ownership for the implementation plan, and to carefully review it prior to production implementation.

A few thoughts:

1) Automate deployments - especially complex deployments, and carefully test the deployment automation process.

2) Set up your development/QA environments to match the production environment as closely as possible.  Compare the relevant portions of the of the dev/QA and prod environments before each production release - and it is a great idea to automate this step.

Require resolution of every discrepancy before the new change can move to production.

3) Require developers to carefully document every change made in the development environment - code changes, setting, new queues, config file changes, new/updated code libraries, os changes, etc.  Require every person or department that has a role in the development, testing, and deployment to review, update, and approve the implementation plan.

4) Hold a pre-implementation review meeting to carefully go through each item in the implementation plan, explain and discuss the required timing and responsibility for each implementation item, and get approval from each of the teams involved.

5) Develop an implementation plan template, and any time there is a deployment failure or post-deployment issue, review the implementation plan and template and address the deficiency.  Also update the template as new applications, tools, and technologies are implemented to make sure that any unique implementation considerations for those items are addressed.

There is no "one size fits all" implementation checklist that will work for every shop, but if you have change management problems, many organizations find it is well worth the time, effort, and money to bring in an experienced consultant to help design a change management process for your organization.

- Gary Patterson
The checklist you describe sounds to me a lot like a test plan for QA.  That's generally where you go through things like making sure all environments have been considered, what happens if you upload too large of a file etc.

Unfortunately there's no recipe that I'm aware for building such a plan.  That's where the skill of a QA team lead or QA members comes in (usually working closely with a dev team lead or dev members) to formulate the right plan and cover all of the bases.  You can talk about things like "code coverage" and other measures of test completeness but as you point out there are lots of cases where code can execute correctly in one situation but fail in another.

I think asking for a generic plan rather implies it's something formulaic when I think it's really a skill.  A bit like asking for a checklist of steps needed to build a fully working app.  We as developers know there is no such checklist.  There may be one day, but our skills as a community haven't reduced development to a simple process and so far I don't think we have for QA either.

Just my opinion,

zzynxSoftware engineerCommented:
Just to let you know that I completely agree with Doug's comment.
SquadlessAuthor Commented:
great reply! 5 stars.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.