{"id":484,"date":"2012-03-15T06:57:00","date_gmt":"2012-03-15T06:57:00","guid":{"rendered":"https:\/\/opstree.com\/blog\/\/2012\/03\/15\/release-strategy-for-java-web-based-projects\/"},"modified":"2019-08-02T10:43:09","modified_gmt":"2019-08-02T10:43:09","slug":"release-strategy-for-java-web-based-projects","status":"publish","type":"post","link":"https:\/\/opstree.com\/blog\/2012\/03\/15\/release-strategy-for-java-web-based-projects\/","title":{"rendered":"Release Strategy for Java Web based projects"},"content":{"rendered":"<div dir=\"ltr\" style=\"text-align:left;\">In this post I&#8217;ll be discussing about the 2 strategies that&nbsp; we can follow for releasing a Java based web project.<\/p>\n<p>A project can be primarily released in two ways<br \/>\n&nbsp;&nbsp;&nbsp; Incremental Release<br \/>\n&nbsp;&nbsp;&nbsp; Full Release<\/p>\n<p>Incremental Release is done in big projects which has multiple modules &amp; usually few modules gets updated between two releases. It makes sense to include only updated modules in release archive and during deployment only update those modules in application server.<\/p>\n<p>Full release is usually done in small projects where the release archive contains all the components and then this release archive can be deployed to the application server as a whole<\/p>\n<p>Both incremental &amp; full release strategy has their pros &amp; cons, where full release strategy scores in simple release archive generation &amp; deployment incremental release has upper hand in space usage by only having modified components in it, although it brings overhead when doing rollback.<\/p>\n<p>Release Steps in Incremental Release Strategy: If you are following incremental strategy in general you need to perform following steps<\/p>\n<p>1.) Checkout the latest code for the release<br \/>\n2.) Generate the list of components which needs to be deloyed for the release<br \/>\n3.) Generate the release archive based on the list of components<br \/>\n4.) Stop the server(If hot deployment of components is not available)<br \/>\n5.) Take the backup of existing application on application server as we may need to do rollback in case of any issues<br \/>\n6.) Replace the components in application server with the components in the release archive<br \/>\n7.) Start the server(If hot deployment of components is not available)<\/p>\n<p>Release steps in Full Release Strategy: As explained earlier Full release strategy is fairly simple, steps involved are:<br \/>\n1.) Checkout the latest code for the release<br \/>\n3.) Generate the release archive for whole application<br \/>\n4.) Stop the server(If hot deployment of components is not available)<br \/>\n6.) Deploy the release archive to the application server<br \/>\n7.) Start the server(If hot deployment of components is not available)<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>In this post I&#8217;ll be discussing about the 2 strategies that&nbsp; we can follow for releasing a Java based web project. A project can be primarily released in two ways &nbsp;&nbsp;&nbsp; Incremental Release &nbsp;&nbsp;&nbsp; Full Release Incremental Release is done in big projects which has multiple modules &amp; usually few modules gets updated between two &hellip; <a href=\"https:\/\/opstree.com\/blog\/2012\/03\/15\/release-strategy-for-java-web-based-projects\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Release Strategy for Java Web based projects&#8221;<\/span><\/a><\/p>\n","protected":false},"author":150552946,"featured_media":29900,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[1],"tags":[44070,1017,3490198,12397870],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/opstree.com\/blog\/wp-content\/uploads\/2025\/11\/DevSecOps-1.jpg","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/pfDBOm-7O","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/484"}],"collection":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/users\/150552946"}],"replies":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/comments?post=484"}],"version-history":[{"count":1,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/484\/revisions"}],"predecessor-version":[{"id":838,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/484\/revisions\/838"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/media\/29900"}],"wp:attachment":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/media?parent=484"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/categories?post=484"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/tags?post=484"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}