Application Lifecyle Management (ALM)Tech Talk

Contents 01 Business Process Focus

02 Version control

03 Development

04 Build

Business Process Focus

• Order to Cash

• Free Text Invoice

• Receipt Journal

• Procure to Pay

• Purchase Order

• Vendor Invoice

• Vendor Payment

• Core Financials

• General Journal

• Run Financial Reports

• Year End Close

Business process modeler

Business Process Focus

• Synchronize with Microsoft Azure DevOps (DevOps)

• Do review processes and track the progress of your implementation project

• Do associate various work items with requirements and business processes

• Consider that work items include bugs, tasks, backlog items, tests, and documents

Application Lifecycle Management

Version control

• Version control using Azure DevOps (DevOps) is required

• Consistency is the main reason version control is required

• DevOps is the successor of VSTS (blog post)

• Only Team Foundation Version Control (TFVC) is supported (Git is not supported)

• Git is the default so make sure to change it before creating the project

• Version control has well known benefits

• Code backups

• Rollback capability

• History and traceability

• Supports branching

Version control

• Primary purpose is storing the source code

• Customizations

• ISV products

• Hot fixes

• The source code for Finance & Operations is primarily the XML (text) files that make up the Application Object Tree (AOT)

Version control

• DevOps accounts are free

• Includes 5 Basic licenses that allow access to the code

• MSDN subscribers get code access without using a Basic License

• Additional Basic licenses can be purchased in the Azure portal

• Includes unlimited Stakeholder licenses that allow access to work items

• Finance & Operations usage of DevOps is standard, so all documentation and reference material are applicable

• LCS code upgrade uses the Trunk/Main branch as input and the output is put in a new branch under the Releases folder

• $/<project>/Releases/8.0.24.0_U1_2018-04-05T03.56.07

Version control

• Do have the owner of the intellectual property (IP) own the DevOps account

• Microsoft recommends the customer own the IP and the DevOps account

• Do connect the DevOps account to the owner’s Azure Active Directory (AAD) for user authentication

• The linked Azure subscription is used to purchase extra DevOps user licenses if needed

• Consider the default URL format changed with the change to DevOps

• The VSTS URL format still works and is required by LCS

• VSTS format: https://<customerorg>.visualstudio.com/project

• DevOps format: https://dev.azure.com/<customerorg>/project

Version control

• Consider using the minimum branching option

• Single branch (Trunk/Main)

• Main: check in, testing in the tier 2+, and deploying to production

• Changes that fail validation are removed or fixed before retesting in the tier 2+

• Consider that everything in a branch will be included in a build of that branch

Version control

• Do use the preferred branching option

• Dev, Test and Release branches

• Dev: developer check in and testing with development data (Trunk/Dev)

• Test: deploying to the tier 2+ and testing with current production data (Trunk/Main)

• Release: retesting in the tier 2+ and deploying to production (Trunk/Release)

Version control

• Consider the movement of code between branches

Normal

Full reset

Version control –Dev branch (Trunk/Dev)

• Do map development machines to the dev branch

• Do use frequent check ins to keep work safe

• Do check in the changes for all features

• Do only include changes from one feature in each changeset

• Consider the cost of a bad checkin when determining the build trigger

Version control – Test branch (Trunk/Main)

• Do only merge features from the dev branch to the test branch after successful development testing

• Do merge each feature in a separate change set

• Do start builds manually

• Do not map any development machines to the test branch

Version control –Release branch (Trunk/Release)

• Do only merge features from the test branch to the release branch that are ready for production

• Do merge each feature in a separate change set

• Do start builds manually

• Do not map any development machines to the release branch

Version control – anti-patterns

• Do not map a development machine’s packages folder to the test or release branches

• Do not check in changes directly into the test or release branches

• Do not check in changes for more than one feature in a single changeset

• Do not mark deployable packages from the dev and test branches as release candidates or install them in production

• Do not merge untested features into the release branch

Version control

Hotfix Management - Environment Strategy

Release

Main

Dev C

Dev BBuild Def 1

Build Def 2

Sandbox 1(Unit Test)

Sandbox 4(Acceptance Test)

Dev A

Release 1 cutoff X++ Hotfix / Binary

Regular task

Check LCS

Release 2 Build

Hotfix Build

Tier 2+

Production

Sandbox 2(Acceptance Test)

Sandbox 3(Unit Test)

Structure of test

requirements should

correspond to

testing process

Branches

Packages and models

Package

• A package is a compilation and deployment unit of one or more models

• A package includes metadata, assemblies, and other resources

• A package does not contain source code

• One or more packages can be added to a deployable package which is the vehicle used for deployment on runtime environments

• A package is also referred to as a module (not model)

• A package has a top level folder in the metadata folder in version control

• e.g. <packages>\ApplicationSuite

Package –Windows Explorer

Model

• A model is a group of source elements, such as metadata and source files, that typically constitute a distributable software solution

• A model is a design-time concept that contains various forms of source code

• The key to a model is its descriptor

• A model has a folder in the package folder in the packages folder

• e.g. <packages>\ApplicationSuite\Foundation

• The descriptor is stored in the descriptor folder of the package’s folder

• e.g. <packages>\ApplicationSuite\Descriptor\Foundation.xml

Model –Windows Explorer

Development

A day in the life of a developer

• RDP to the development machine

• Perform a “Get latest” in version control

• Develop features

• Collaborate with business users by using the development VM’s Finance & Operations web site to test features or set up data (must RDP to a VHD to use the web site)

• Check-in code to version control when the feature is complete

• It is quick and easy to get a new development machine (or a new developer) up and running

Development

Configure a new development machine

• Open Visual Studio (VS) and sign in using the account connected to your VS license

• Connect VS to version control

• Map version control folders to the local machine

• Build the needed models

Development

Configure a new development machine – workspace mappings

Development

• Do make sure each developer has their own DevOps license and login

• Do make sure each developer has their own development machine

• Do make sure each developer has their own Visual Studio license

• Do reference a feature work item with each check-in

• Consider including automated tests using the SysTest framework

• Consider using test driven development techniques

Development

• Consider non-functional requirements such as the expected performance and throughput

• Implementing more performance than is necessary will take longer

• Implementing less performance than is necessary will result in rework that will likely be expensive and time consuming

Development –KB install (before 8.1)

• Do install the KB from the command line

• Help topic: Install metadata hotfixes in development environments

• Do use the version control option

• Do use the following procedure

1. Do execute the prepare

2. Do check in the pending changes

3. Do execute the install

4. Do check in the pending changes

Development –KB install (One version)

• Do remember that putting a KB in version control is not applicable starting with application version 8.1 because all Microsoft code is being released as a binary update

• Do remember this is possible because of the switch from overlayering to extensions

Development – ISV products

• Do check the ISV source code into version control if you don’t have a binary deployable package from the ISV to use in tier 2+ environments and production

• Do check the ISV binaries into version control if you have a binary deployable package from the ISV to use in tier 2+ environments and production

• Do install ISV source code on development machines as needed if you have a binary deployable package from the ISV to use in tier 2+ environments and production

• Consider ISV source code may be shared with a model file that was created manually or created by an automated build

Development – anti-patterns

• Do not let developers hold their changes on a development machine for too long without checking into DevOps

• Do not let developers share a development machine

• Do not let developers share DevOps logins to ensure traceability and accountability of changes

• Do not check in changes for multiple features in a single check in

• Do not use VS to create deployable packages

Build

• This topic refers to automated builds using a build machine

• A build is the process of taking the source code and producing binary files that a system can run

• No code can ever run without performing a build first

• A database sync also requires a build first because the schema is retrieved from the assemblies (and not the XML files)

• In AX 2012, the build was taken for granted because even production environments had the ability to perform a build

Build

• Automated Builds serve multiple purposes

• Make sure the code compiles without errors

• A common scenario is the objects a developer created on their development machine but did not check-in to DevOps (forgot, etc.)

• Perform automated testing after successful builds

• SysTest based tests can be run as a part of a build

• Creates a deployable package when the build succeeds

• Microsoft recommends creating a single deployable package that contains all packages

• Builds can be started manually or automatically

Build

DevOps build system provides “triggers” for builds:

• Scheduled builds

• e.g. Start a build nightly at 6 PM

• Continuous Integration

• Start a build as soon as a check-in is performed

• Gated check-in

• Start a build when a check-in is attempted; only allow the check-in to commit if the build runs without error (can be very useful in conjunction with automated testing during build)

• Manual

• Start a build on demand from the DevOps web site

Build –Dev branch

• Do schedule an automated build at least daily to ensure errors are caught early

• Do verify the developer remembered to add or update all the objects in version control

• Do find build errors caused by conflicts between developers

• Consider using the continuous integration or gated check in build triggers

• Do not install dev branch deployable packages on any environments

Build – Test branch

• Do start builds manually

• Do install deployable packages on a tier 2+ environment for testing using recent production data

• Do not mark deployable packages from the test branch as a release candidate (or install them on production)

Build –Release branch

• Do start builds manually

• Do install deployable packages on a tier 2+ environment for testing using recent production data

• Do only mark deployable packages from the release branch as a release candidate when they are ready to go to production (only release candidates can be installed on production)

• Do not skip testing a deployable package from the release branch because the same features were validated in the test branch

Build –Build machines

• Do have one build machine for each application version

• Do create a build definition for each branch

• Do create a build definition for each build trigger

Build

• Do use consistent naming for your deployable packages

• Pattern: <company> <branch> <app version> <DevOps build number>

• Sample: Widgets.com Test 8.0 2018.08.06.01

• Do add additional information to the description such as a bug or KB

Build – anti-patterns

• Do not RDP to the build machine

• Everything you need to do can be done from the DevOps web site

• Do not open VS or map it to the branch in version control

• Do not use Visual Studio to create a deployable package

• The deployable packages will contain all code on the development machine including experimental code, incomplete features, etc.

• The deployable package may not include all the modified packages which will mean it is not independent and testing results could vary depending on the previously installed deployable packages

Build

• Do not use Visual Studio to create deployable packages

• This is a typical deployable package created by a build machine that contains a customer module and Microsoft modules due to hot fixes

Build

• Do not use Visual Studio to create deployable packages

• A deployable package created by a build machine is self-contained because it contains all applicable modules

Build

• Do not use Visual Studio to create deployable packages

• A deployable package with one module requires you to make sure a compatible combination of modules is installed

Deployment

Binary deployment to an environment

• The build creates a deployable package containing the binaries needed for a runtime environment

• Go to Build & Release in DevOps and find the build

• Click on View build results

Deployment

• Click on Artifacts

• Click on Packages

Deployment

• Expand the Packages folder

• The filename that begins with AXDeployableRuntime is the deployable package that is ready to upload to the Software deployable package asset type in the LCS asset library

• The filename that begins with AXModelSource is the source code from the build

• Download the deployable package by clicking on the three dots and choosing Download

Deployment

Binary deployment to an environment

• The deployable package can be deployed to a Finance & Operations environment

• Upload it to the LCS Asset Library

• Use Maintain → Apply updates to install it on an environment

Deployment –Uninstalling a module

• Do deploy an update with all references to the module to be uninstalled removed

• Do deploy an update to the module to be uninstalled with all code removed

• Include one empty class in the module to be uninstalled

• Do deploy a deployable package to uninstall a module separate from any another deployments

• Topic: Uninstall a package

© Copyright Microsoft Corporation. All rights reserved. © Copyright Microsoft Corporation. All rights reserved.

Thank you.