patches vs application packages for bug fixing and new functionalities

Certified Lead Developer

Hi all,

I wanted to ask what is the best practice to deploy bug fixes. A patch or a new application package?

In our customer normally a new application package is created per release with a description of the bugs fixed. In case of Regression Errors it is easy to identify which components Need to be taken out.It is also good for tracking purposes.

If we use patches we lose all of that. However it will be nice to have one application only. With the time, there will be many packages for just one application and it can become messy.

Is there a best practice for this?

Many thanks!

  Discussion posts and replies are publicly visible

Parents
  • What code progression between environments are you using?  Is it a typical setup i.e. Dev -> Test -> Production?

    If so then consider what I usually do: in the Dev environment, each ticket / story gets its own app package (usually named after the ticket number with brief detail in the package name and extended details in the description if necessary).  When different tickets are going to be deployed together in one sprint, then whoever deploys to the TEST environment initially creates an app package there for the whole sprint deployment.  Then, instead of exporting the individual ticket app packages as independent applications, we take a patch consisting of all [updated] objects in that package, and import it as a patch into the whole-sprint app package in TEST.  During testing / UAT, any necessary fixes can then be imported as new patches in a similar manner.

    Later, when it's time to deploy to production (and/or other higher environments first), the whole app package from the test environment is exported, and imported whole into production.

    I don't assume that all projects do it this way, but this seems to be a fairly common deployment pattern and is my recommended approach when that is the case.

Reply
  • What code progression between environments are you using?  Is it a typical setup i.e. Dev -> Test -> Production?

    If so then consider what I usually do: in the Dev environment, each ticket / story gets its own app package (usually named after the ticket number with brief detail in the package name and extended details in the description if necessary).  When different tickets are going to be deployed together in one sprint, then whoever deploys to the TEST environment initially creates an app package there for the whole sprint deployment.  Then, instead of exporting the individual ticket app packages as independent applications, we take a patch consisting of all [updated] objects in that package, and import it as a patch into the whole-sprint app package in TEST.  During testing / UAT, any necessary fixes can then be imported as new patches in a similar manner.

    Later, when it's time to deploy to production (and/or other higher environments first), the whole app package from the test environment is exported, and imported whole into production.

    I don't assume that all projects do it this way, but this seems to be a fairly common deployment pattern and is my recommended approach when that is the case.

Children
  • Certified Lead Developer
    in reply to Mike Schmitt
    1. Thanks Mike. I like your Suggestion. I also like the idea of having multiple individual patch-packages (rather than patches applied to the main app) because that way we can trace at any time  what was deployed on each package. In the description of each package we add the IDs of all the defects included