Deploying Solution Enhancements to Production
Upcoming SlideShare
Loading in...5
×
 

Deploying Solution Enhancements to Production

on

  • 678 views

 

Statistics

Views

Total Views
678
Views on SlideShare
678
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • OLD AGENDA:Overview of the “Problem” (scenarios)Why do we care about thisDiscuss common deployment challengesSimple -Moving from dev to prodMore complex - Parallel developmentOur ApproachRecommended environment picture of Dev/Test/ProdKeeping them in syncFlow chart of the processFull import vs deltaWhy it is importantOther considerations (see Russ’ slide)TerminologyBaseline, reversible, equivalency, patches/deltaTools that you needShare best practices for managing large, complex deploymentsWalk through some example deployment scenarios
  • Talking Points:1. [Accurate Deployments] Just because a package imports successfully doesn’t mean that the desired result is achieved
  • Deployment package Should be assigned a sequence number or build numberBaselineDoesn’t typically change during a development cycle, but there are special cases where it might (i.e. ‘Service Pack’ deployment during production. Or production fix was deployed which impacts current development project.Most likely a standard solutions DB
  • Define Test Strategy which includes:Cases / ScriptsTest DataTest EnvironmentsTest Passes / PhasesIssue PriorityHow do we know when we are done testing?Important for regression testing in future phases
  • * Identify package with a number for tracking* Store in a source control or similar repository
  • I agree. This is no longer needed.
  • Not RequiredBenefits:Branched DevelopmentMinimized riskControlHistoryTools
  • Need to clarify the ‘Merge Conflicts’ step in the process. The Import tool will merge the changes automatically, so no need to merge changes found. However, we do need to merge changes found in the baseline or inadvertent changes identified from the developers environment (accidentally moved another field’s location on the form and a change was identified by doing a comparison)
  • Fixes are processed at the end of the import processAny folder name can be used, but ‘Fixes’ is a best practiceFiles are processed by name in alphabetical orderYou cannot add package elements from other packages, but can add or edit properties / relationships from ItemTypes in other packagesFixes is best used for: Handling deletesItems that are not in the current package

Deploying Solution Enhancements to Production Deploying Solution Enhancements to Production Presentation Transcript

  • aras.comCopyright © 2013 Aras. All Rights Reserved.DOMOREA C E 2 0 1 3
  • aras.comCopyright © 2013 Aras. All Rights Reserved.A C E 2 0 1 3Deploying SolutionEnhancements to ProductionLearn about Best Practices for deployingchanges, extensions, or new solutionsfrom development to production
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 3Agenda Deployment Challenges Getting Started Environment Planning Terminology Our Approach Tools that you need Walk through some example deployment scenarios Common Pitfalls
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 4Deployment Challenges How do you insure accurate deployments? How do you avoid regressions? How to manage parallel development? How do you keep environments in sync? How do you plan deployments?
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 5Scenarios for Today Moving enhancements to aproduction environment Parallel or multi-resourcedevelopment of a solutionDevTestProductionDev
  • GETTING STARTED
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 7Getting Started Establish your environment Establish your starting point or baseline Establish a source control plan Plan your deployment strategy Establish a validation plan
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 8The Development Environment 3 Environments minimum Development This is where you work Test/QA/Staging Imports are tested here User validation is conducted here Should always reflect yourbaseline to start Production This is your baselineDevTestProduction
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 9Terminology Deployment Package Complete set of all development changes Must be fully applied for proper deployment Typically contains full AML definitions Depends on a pre-defined Baseline Patch Subset of development changes Provides for quick and pointed updates Can eliminate the need for a merge May contain AML snippets vs. full definition Must be applied in a particular order Baseline A simple snapshot of system functionality Defines a starting point for development Doesn’t typically change during a development cycle
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 10Importance of Baselines Provides a solid foundation forthe development / deploymentprocess New environments can be builtusing the baseline as a startingpoint Eliminates the issue of a ‘MovingTarget’ Critical for accurate deployments
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 11DevelopmentDevelopmentExample BaselineStandardArasInnovatorDevelopmentNew Baseline(Phase 2 Production System)Target(Phase 1 Production System)New Baseline(Phase 1 Production System)MergePoint
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 12Source Control Plan Establish a system for how and where deploymentpackages will be stored Source control File server Establish a naming convention for these packages Establish where the baseline will be stored Think about the sequence in which features will bedeployed
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 13Plan your deployment Determine how your solution will be deployed All at once Separate deployments Deployment strategy can help define packaging Establish a validation plan
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 14Validation plan Defines how you will test for accuracy Define Test Strategy which includes: Use Cases/Test Cases Test Data Test Environment How do we know when we are done? Don’t underestimate this !
  • OUR APPROACH
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 16Development &PackagingDevelopment ProcessPlan Develop Build Deploy Test RolloutProject PlansDeployment PlansTest & Validation strategyBaseline EstablishedExport PackagesBuild Cleanup scriptsPackage Code Tree ChangesBuild Custom DLLsRun cleanup scriptsMerge activitiesImport packagesDeploy CodeTree ChangesDeploy Custom DLLsExecute validation planRun test scriptsRepeat deploymentsteps in production
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 17Deployment ProcessSingle Developer SolutionExportPackage(s)Compareto BaselineCreateDeploymentPackage(s)Import intoTestMergeConflictsPlan Develop Build Test RolloutDeployPlanDevelopBuildTestRollout
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 18Deployment ProcessMultiple Developer SolutionExportPackage(s)Compareto BaselineCreateDeploymentPackage(s)Import intoTestMergeConflictsPlan Develop Build Test RolloutDeployPlanDevelopBuildTestRolloutMerge Development andBaselineThis is a 3 way Compare and Merge
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 19Exporting Packages Done using the Aras Export tool Use the same version of the Import/Export tools toestablish the baseline and export your development Use Tools like the Aras Customization report toassist with packaging Usually best to export entire packages to help withthe merge process Export the same packages from development andbaselineExportPackage(s)Compareto BaselineCreateDeploymentPackage(s)Importinto TestMergeConflicts
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 20Comparing Baselines Requires a good XML compare utility You need to understand AML and the significance ofchanges Don’t ignore differences.. Make sure that you understand the reason for the diff. Use a 3 way compare tool when multipledevelopers are involvedCompare toBaselineExportPackagesCreateDeploymentPackage(s)Importinto TestMergeConflicts
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 21Merging Conflicts The focus is CONFLICT Resolution A difference is not necessarily a conflict A conflict could be: An AML element that differs from the baseline AML elements that wont produce the same result The Aras Import tool will merge changes that are notconflictedMergeConflictsExportPackagesCreateDeploymentPackage(s)Importinto TestCompareto Baseline
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 22Creating a Deployment Package May require some scripts for pre-processing Deleting items Versionable items Should be a full and complete package in most cases There are some cases for delta files and patches Name package in accordance with your plan Store the package in the defined location Notify the teamCreateDeploymentPackageExportPackagesMergeConflictsImportinto TestCompareto Baseline
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 23Importing into Test Target system MUST be equivalent to the baseline Execute any pre-processing scripts Import the deployment package using the Aras ImportTool Move on and execute your validation plan When Issues are Identified: Fix them in Development and repeat Patching test is OK but you should repeat the whole process tosimulate the deployment processImport intoTestExportPackagesMergeConflictsCreateDeploymentPackageCompareto Baseline
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 24Synchronizing EnvironmentsDev 1Dev 2TestProdCheckIn / OutSourceControl RefreshBuilds /Patches
  • TOOLS THAT YOU NEED
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 26Tools – Source Control GIT CVS SourceSafe Subversion File System Etc.
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 27Tools -XML Diff / Merge Beyond Compare Altova DiffDog KDiff3 Etc.
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 28Tools – Aras Import / Export Move solution items between environments via AML Console Upgrade Command line version of Import / Export Tools Nash Apply AML directly to the Innovator Server AML Studio Similar to Nash, but with intellisense. Community Solution
  • EXAMPLES
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 30Example – Simple ChangeSingle DeveloperAdd new field to existing Part Form:
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 31Deployment ProcessSingle Developer SolutionExportPackage(s)Compareto BaselineCreateDeploymentPackage(s)Import intoTestMergeConflictsPlan Develop Build Test RolloutDeployPlanDevelopBuildTestRollout
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 32Compare AMLBaseline vs DevelopmentBaseline DevelopmentBeyondCompare
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 33DeployImport Tool Nash / AML StudioTest / ProductionOR
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 34Verify
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 35Example 2 - A two developer ScenarioDeveloper 2 - Change Label, Name of fieldDeveloper 1 – Adds ‘Weight’ fieldTwo Developers workingin parallel make changesto the same Form.Changes are made inseparate environments
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 36Deployment ProcessMultiple Developer SolutionExportPackage(s)CreateDeploymentPackage(s)Import intoTestPlan Develop Build Test RolloutDeployPlanDevelopBuildTestRolloutMerge Development andBaseline
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 37Development & Baseline CompareFirst DifferenceBaseline Developer 1 Developer 2KDiff3Developer2 has modifiedthe label and nameDeveloper 1 has notchanged the baseline hereThis is a DIFFERENCE butnot a CONFLICTNo Merge Required!
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 38Development & Baseline CompareSecond DifferenceBaseline Developer 1 Developer 2KDiff3Developer 1 has added theWeight field to the formDeveloper 2 has notchanged the baseline hereThis is a DIFFERENCE butnot a CONFLICTNo Merge Required!
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 39DeployImport Tool Nash / AML StudioTest / ProductionOR
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 40Verify
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 41Example of a conflictBaseline Developer 1 Developer 2KDiff3Developer2 has modifiedthe label and nameDeveloper1 has also modifiedthe label and nameThis is a CONFLICTMerge Required!
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 42Handling Special Cases Special cases include: Handling Deletes Edit properties or relationships from items in other packages You can execute custom AML during the import process Place AML files in a folder with any name ‘Fixes’ for folder name is best practice Files are processed by name in alphabetical order Fixes are executed at the end of the import process Pre-Processing can be done by using multiple packages Copy snippets of AML during Diff Analysisas a starting point Patches can be created by editing the exported AML
  • aras.comCopyright © 2013 Aras. All Rights Reserved. Slide 43Common Pitfalls Manual changes directly in Test or Production Lack of source control Deferring deployment planning too late in the project Insufficient Team Communication Waiting too long to synchronize environments Too many manual deployment steps Failure to adjust baseline if changed during project
  • aras.comCopyright © 2013 Aras. All Rights Reserved.A C E 2 0 1 3Questions?