Re: Recommendations for Automating Deployments and then dev, qa, uat, prod testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fletcher, On 1/23/2010 11:17 AM, Fletcher Cocquyt wrote: > This process is not perfectly defined and slow - the developer's check all the > code into SVN and tag the release - ops checks it all out and builds it on the > tomcat nodes with the dev supplied ant build.xml. This can take several > minutes > per app per node and if there are any errors the 4-6am window is done. So, you build the project once for each target node? Why not do a single build and then copy the complete WAR onto each target node? Something like this: $ svn checkout $ ant test $ ant war $ scp mywebapp.war u...@node1: $ scp mywebapp.war u...@node2: $ scp mywebapp.war u...@node3: ... Of course, you'd need to put the WAR file in the right place, bounce Tomcat, and possibly run any upgrade scripts required before the webapp would work properly, but that's the general idea. > Ideally, the entire release to production process would be such a well > defined, > quick and pre-tested event, than ops would only be notified if the 4am > deployment failed and the automated rollback also failed. It's always a good idea to smoke-test a release, even if it's been pre-tested, because something stupid like the dev db password being used in production can really ruin your day if you're not paying attention. > So questions about the things maven seems to address: > testing: unit, integration testing - article mentions selenium? > sensitive data: database passwords (can these be securely handled in maven?) We have a set of ant scripts that are checked into CVS, but they utilize a user-specific ~/.ant.properties file that defines all kinds of things like installation directories, context paths (i.e. the name of the WAR file to build), and certain other configuration parameters that are merged-into the source, etc. at build time. Thus, in production, we have the production database credentials stored here as well as other things. These values then don't ever make it into our source repo, so we don't have to worry about revealing secrets through that mechanism. Selenium is a UI testing framework that, frankly, is one of the coolest things I've ever seen. Its very fragile, though, because you have to make sure that every screen in your UI includes mark-up to be able to reference everything, plus every time you make a change, you need to change your tests. This isn't always the case with code modifications: you are more likely to change the implementation of a method or class than to change the interface, and so most tests should pass with no modification. I would recommend that Selenium-based testing only be done as part of your develop/test cycle, and not make it a part of the production build. For unit testing, I would also say that it should be a part of your dev/test process, and leave it out of the production build. You could mandate that tagging the repo for a release requires a complete set of unit and/or integration tests be run against what will be tagged or something. Presumably, if it passes tests in dev/test, it will pass those offline tests in production, too. Ideally, your testing environment simulates production in every way except maybe for a handful of service endpoint locations (URLs), credentials, and, of course, physical/logical environment. The process for deploying to production should be to take the successfully-tested WAR file(s) from the testing environment, update the configuration to a production one, push those WAR files directly into production, then do a smoke test to make sure that your production configuration was applied properly. You could even double-check this before the actual deployment if you don't trust your tools/process. > Additional, medium-long term goals: > Standardize the development environment and processes. We've always been a fan of our ant scripts. In production, this is essentially the upgrade procedure: $ cvs checkout $ ant tomcat-stop (run database upgrade script) $ ant install-clean install tomcat-start (perform smoke tests) This kind of thing even works in development: all ant targets are regularly exercised, because they are used in all environments. There's no special set of procedures for production... it's just like dev/test/demo. > Leverage the virtual infrastructure we have built with vmware: have the > developers use standard VM images from templates (ensure consistent JDK, libs > etc), integrate with lab manager/vApp/VMware Studio concepts. Heh... if you wanted to, you could rotate VM instances in and out of production. Your upgrade procedure (for the app servers) could simply be to switch the IPs of the testing system(s) to the IPs of the production system(s): instant upgrade, and you know you've already tested everything :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkteG6AACgkQ9CaO5/Lv0PAvgQCeNPd0etF/kbXtn5FxPPzp9BJv 9
Re: Recommendations for Automating Deployments and then dev, qa, uat, prod testing
Continous Integration sounds like a better solution for you. Your apps will be built and tested as soon as the developer checks in their code in SVN. Have a look at http://cruisecontrol.sourceforge.net Using CruiseControl will ensure that the developers wont check-in anything with errors on it. -- D On Sun, Jan 24, 2010 at 5:22 PM, Fletcher Cocquyt wrote: > Fletcher Cocquyt stanford.edu> writes: > > > > > Hi, this question is coming from the operations team perspective. > > Currently our (small 3 member) ops team is responsible for deploying java > apps > > weekly from a set of dozens in a less than great 4am-6am window on > Wednesdays. > ..snip.. > > So questions about the things maven seems to address: > > testing: unit, integration testing - article mentions selenium? > > sensitive data: database passwords (can these be securely handled in > maven?) > > > > Additional, medium-long term goals: > > Standardize the development environment and processes. > > Leverage the virtual infrastructure we have built with vmware: have the > > developers use standard VM images from templates (ensure consistent JDK, > libs > > etc), integrate with lab manager/vApp/VMware Studio concepts. > > > thanks for the feedback & recommendations > In fact we already have one keen developer using Maven, and another using > CI > (hudson) - > > On the medium/long term goal I would like to see us one day deploying to > private > cloud via VMWare's vCloud API > http://communities.vmware.com/community/developer/forums/vcloudapi > or the like. > > Some interesting activity in this area: > http://code.google.com/p/jclouds/wiki/QuickStartTerremark > > Looks like a fun integration project to marry all these together! > > thanks, > Fletch. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Recommendations for Automating Deployments and then dev, qa, uat, prod testing
Fletcher Cocquyt stanford.edu> writes: > > Hi, this question is coming from the operations team perspective. > Currently our (small 3 member) ops team is responsible for deploying java apps > weekly from a set of dozens in a less than great 4am-6am window on Wednesdays. ..snip.. > So questions about the things maven seems to address: > testing: unit, integration testing - article mentions selenium? > sensitive data: database passwords (can these be securely handled in maven?) > > Additional, medium-long term goals: > Standardize the development environment and processes. > Leverage the virtual infrastructure we have built with vmware: have the > developers use standard VM images from templates (ensure consistent JDK, libs > etc), integrate with lab manager/vApp/VMware Studio concepts. > thanks for the feedback & recommendations In fact we already have one keen developer using Maven, and another using CI (hudson) - On the medium/long term goal I would like to see us one day deploying to private cloud via VMWare's vCloud API http://communities.vmware.com/community/developer/forums/vcloudapi or the like. Some interesting activity in this area: http://code.google.com/p/jclouds/wiki/QuickStartTerremark Looks like a fun integration project to marry all these together! thanks, Fletch. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Recommendations for Automating Deployments and then dev, qa, uat, prod testing
How about CI - continious integration server that builds, tests, and deploys the apps if the tests are successful? There are a few great CI servers out there. I happen to use Bamboo from atlassian. All CI use a build tool like ant or maven. CI would make your small ops team superstars. On 1/23/10, Pierre Goupil wrote: > Hello, > > Maven can for sure cover all these needs. But be aware that it has a steep > learning curve and that if someone uses it, everybody should do so. > > Depending upon your role on the project the required level of knowledge will > vary, though. For an operationnal guy it may reduce to launch 2 or 3 > well-defined goal, for most developers, it may reduce to 3-4 more. But in > the beginning, someone will have to study the whole problematic and write > the POM files. > > According to what I see of your need, I'd recommend to do a small-step study > after applying to a professional training: Maven is a very rich tool and > whoever will write the POMs will benefit (regarding cost and hassle) from > not to have and learn everything by himself. > > Plus, it could be a best practice not to put all critical build-system > knowledge in the same hands. > > Regards, > > Pierre > > > > On Sat, Jan 23, 2010 at 5:17 PM, Fletcher Cocquyt > wrote: > >> Hi, this question is coming from the operations team perspective. >> Currently our (small 3 member) ops team is responsible for deploying java >> apps >> weekly from a set of dozens in a less than great 4am-6am window on >> Wednesdays. >> >> This process is not perfectly defined and slow - the developer's check all >> the >> code into SVN and tag the release - ops checks it all out and builds it on >> the >> tomcat nodes with the dev supplied ant build.xml. This can take several >> minutes >> per app per node and if there are any errors the 4-6am window is done. >> >> So my initial goal is a way to better define the requirements around >> deployments >> so we can go from the slow error-proone build from SVN tag, to something >> like >> the quick packaged war file deployment. >> >> One candidate seems to be maven - >> >> http://www.waltercedric.com/java-j2ee-mainmenu-53/361-maven-build-system/1555-deploy-to-tomcat-6-using-maven.html >> >> Ideally, the entire release to production process would be such a well >> defined, >> quick and pre-tested event, than ops would only be notified if the 4am >> deployment failed and the automated rollback also failed. >> >> So questions about the things maven seems to address: >> testing: unit, integration testing - article mentions selenium? >> sensitive data: database passwords (can these be securely handled in >> maven?) >> >> Additional, medium-long term goals: >> Standardize the development environment and processes. >> Leverage the virtual infrastructure we have built with vmware: have the >> developers use standard VM images from templates (ensure consistent JDK, >> libs >> etc), integrate with lab manager/vApp/VMware Studio concepts. >> >> thanks for any feedback / recommendations, >> Fletcher. >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > > > -- > Ad augusta per angusta > > Des résultats grandioses par des voies étroites > -- Sent from my mobile device - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Recommendations for Automating Deployments and then dev, qa, uat, prod testing
Hello, Maven can for sure cover all these needs. But be aware that it has a steep learning curve and that if someone uses it, everybody should do so. Depending upon your role on the project the required level of knowledge will vary, though. For an operationnal guy it may reduce to launch 2 or 3 well-defined goal, for most developers, it may reduce to 3-4 more. But in the beginning, someone will have to study the whole problematic and write the POM files. According to what I see of your need, I'd recommend to do a small-step study after applying to a professional training: Maven is a very rich tool and whoever will write the POMs will benefit (regarding cost and hassle) from not to have and learn everything by himself. Plus, it could be a best practice not to put all critical build-system knowledge in the same hands. Regards, Pierre On Sat, Jan 23, 2010 at 5:17 PM, Fletcher Cocquyt wrote: > Hi, this question is coming from the operations team perspective. > Currently our (small 3 member) ops team is responsible for deploying java > apps > weekly from a set of dozens in a less than great 4am-6am window on > Wednesdays. > > This process is not perfectly defined and slow - the developer's check all > the > code into SVN and tag the release - ops checks it all out and builds it on > the > tomcat nodes with the dev supplied ant build.xml. This can take several > minutes > per app per node and if there are any errors the 4-6am window is done. > > So my initial goal is a way to better define the requirements around > deployments > so we can go from the slow error-proone build from SVN tag, to something > like > the quick packaged war file deployment. > > One candidate seems to be maven - > > http://www.waltercedric.com/java-j2ee-mainmenu-53/361-maven-build-system/1555-deploy-to-tomcat-6-using-maven.html > > Ideally, the entire release to production process would be such a well > defined, > quick and pre-tested event, than ops would only be notified if the 4am > deployment failed and the automated rollback also failed. > > So questions about the things maven seems to address: > testing: unit, integration testing - article mentions selenium? > sensitive data: database passwords (can these be securely handled in > maven?) > > Additional, medium-long term goals: > Standardize the development environment and processes. > Leverage the virtual infrastructure we have built with vmware: have the > developers use standard VM images from templates (ensure consistent JDK, > libs > etc), integrate with lab manager/vApp/VMware Studio concepts. > > thanks for any feedback / recommendations, > Fletcher. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Ad augusta per angusta Des résultats grandioses par des voies étroites
Recommendations for Automating Deployments and then dev, qa, uat, prod testing
Hi, this question is coming from the operations team perspective. Currently our (small 3 member) ops team is responsible for deploying java apps weekly from a set of dozens in a less than great 4am-6am window on Wednesdays. This process is not perfectly defined and slow - the developer's check all the code into SVN and tag the release - ops checks it all out and builds it on the tomcat nodes with the dev supplied ant build.xml. This can take several minutes per app per node and if there are any errors the 4-6am window is done. So my initial goal is a way to better define the requirements around deployments so we can go from the slow error-proone build from SVN tag, to something like the quick packaged war file deployment. One candidate seems to be maven - http://www.waltercedric.com/java-j2ee-mainmenu-53/361-maven-build-system/1555-deploy-to-tomcat-6-using-maven.html Ideally, the entire release to production process would be such a well defined, quick and pre-tested event, than ops would only be notified if the 4am deployment failed and the automated rollback also failed. So questions about the things maven seems to address: testing: unit, integration testing - article mentions selenium? sensitive data: database passwords (can these be securely handled in maven?) Additional, medium-long term goals: Standardize the development environment and processes. Leverage the virtual infrastructure we have built with vmware: have the developers use standard VM images from templates (ensure consistent JDK, libs etc), integrate with lab manager/vApp/VMware Studio concepts. thanks for any feedback / recommendations, Fletcher. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
