Solved

Checklist post application development (JAVA)

Posted on 2014-02-19
4
859 Views
Last Modified: 2014-02-21
Hi,

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.
0
Comment
Question by:Squadless
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
4 Comments
 
LVL 27

Expert Comment

by:dpearson
ID: 39872701
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,

Doug
0
 
LVL 37

Expert Comment

by:zzynx
ID: 39872763
Just to let you know that I completely agree with Doug's comment.
0
 
LVL 35

Accepted Solution

by:
Gary Patterson earned 500 total points
ID: 39873994
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
0
 
LVL 1

Author Closing Comment

by:Squadless
ID: 39876968
great reply! 5 stars.
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
spring maven example issues 3 44
import as existing maven project 3 41
Java array 10 63
MySQL programmer starter 25 29
In this post we will learn how to make Android Gesture Tutorial and give different functionality whenever a user Touch or Scroll android screen.
Today, the web development industry is booming, and many people consider it to be their vocation. The question you may be asking yourself is – how do I become a web developer?
This theoretical tutorial explains exceptions, reasons for exceptions, different categories of exception and exception hierarchy.
In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…

726 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question