Источник: http://www.ksaelen.be/wordpresses/dy...leases-part-1/
==============
“Good release management practices ensure that when your software is built, it will be successfully deployed to the people who want to use it. You have the opportunity to satisfy existing customers and hopefully to win new ones.” It’s a statement coming from a excellent article dicussing 7 ways to improve your releases. Before continuing here, make sure you read the article entirely. It really deals with all of the facets of releases, starting from planning to infrastructure and automation of the process.
Let’s elaborate on a few of the topics in the article and explain how this series will provide a way of doing this for Microsoft Dynamics Ax releases (And remember: It will be A way to do it, not THE way):
Источник: http://www.ksaelen.be/wordpresses/dy...leases-part-1/
==============
“Good release management practices ensure that when your software is built, it will be successfully deployed to the people who want to use it. You have the opportunity to satisfy existing customers and hopefully to win new ones.” It’s a statement coming from a excellent article dicussing 7 ways to improve your releases. Before continuing here, make sure you read the article entirely. It really deals with all of the facets of releases, starting from planning to infrastructure and automation of the process.
Let’s elaborate on a few of the topics in the article and explain how this series will provide a way of doing this for Microsoft Dynamics Ax releases (And remember: It will be A way to do it, not THE way):
- Plan your releases!
Captain obvious to the rescue.. But let’s be honest, how many of you technicals are often forced into a situation where an ad hoc release is asked…? So it is of the utmost importance to establish a regular release cycle. That way, all of the stakeholders have a clear view on the timetable and when to expect to see progress. Your release cycle is not about when your customer wants the release. It’s about when you can deliver it to the desired level of quality.One thing we have done to support planning releases and follow up the time spent on releases, is creating a custom work item type ‘Release’. On that custom work item type, we can put all the details concerning the release (Title, Original Estimate, Actuals, linked queries to be able to query for the work items related to this release)
- Establish your release infrastructure early
For Dynamics projects, this is even more important. Especially because a full Microsoft Dynamics AX environment requires quite some resources. This is one of the most difficult topics to discuss when it comes to figures. Having all of the needed environments (DEV, QA, UAT, STAGING, MIGRATION, PRODUCTION) will make you expensive as opposed to other vendors stating that a DEV, QA and PRD are enough. But in the end, the customer will notice during the implementation that he does need those to do things as they should be done.
- Release notes are not optional!
And yet I still come accross projects where releases are done without informing the customer what has actually been changed. And it’s all about perception here. You do not want all of the bugs to be on the notes, but the ones reported by the customer do need to be mentioned. That way, customers have the notion of progress and key users can be informed about the changes.To achieve this, we have done two things. First we have added a field Release note (No / Yes) to the work item types available on release notes. This way we can actually filter out the things we do not want on the notes. Secondly, we created a Visual Studio Team Explorer add-in to enable us to generate release notes based on a selected work item of the type Release. Through the use of the OpenXML SDK, we generate a word document containing a couple of sections and each section is linked to a work item query.
- Automating builds and deployments
Releasing Microsoft Dynamics AX can be very time consuming. Compiling the entire codebase takes some time. The database synchronization is also heavy and is prone to ID conflict errors if you do things as you shouldn’t be doing.To avoid spending a lot of time on releases, we have automated the TFS build process and enabled ReleaseManagement for Visual Studio to do the deployments for us. Daily builds are running, daily deployments to a Test environment are available and all of it without any human interaction. For these two topics, we are not going to have posts in this series because a lot of posts are already available.</p>
Posts concerning TFS Builds / ReleaseManagement deployments for AX
TFS build activities for AX
Customizing build templates
ReleaseManagement installation guide
Axilicious – ReleaseManagement and Ax Part 1 – Overview
Axilicious – ReleaseManagement and Ax Part 2 – Creating the first tool
Axilicious – ReleaseManagement and Ax Part 3 – Creating the deployment sequence
Источник: http://www.ksaelen.be/wordpresses/dy...leases-part-1/
