Application lifecycle management

  • 10 minutes

Application lifecycle management (ALM) is the management of computer programs, which includes managing requirements, software architecture, software development, software maintenance, change management, continuous integration, project management, and released management.

ALM should be used to help streamline your development process. ALM allows for better control and collaboration, helps keep your approach consistent, and streamlines deployment.

In Dynamics AX 2012, ALM is optional, along with version control and automated builds. Dynamics AX 2012 deployment is also manual. Conversely, ALM, version control, and automated builds are mandatory in finance and operations apps, and deployment is automated by using Lifecycle Services.

The following sections closely examine each of these now mandatory ALM tools.

Application lifecycle management differs from Dynamics AX 2012 because developers are now in their own dedicated developer box and are using source control.

ALM involves three phases: develop, build, and deploy.

The three phases of application lifecycle management and the tools that are involved.

Within the develop phase, developers will work within their own isolated developer environment by using source control that is powered by Microsoft Azure DevOps to manage code versioning. When the code is ready, you can move the code to the build phase. When the build is completed and errors are resolved (as needed), you can create an Application deployable package and then deploy your code to user acceptance testing (UAT) within Lifecycle Services. When the code has been tested, you can mark the package as a release candidate for a move to production.

Note

The production environment is fully managed by Microsoft. Therefore, for infrastructure as a service (IaaS) deployments, you need to create a service request for Microsoft to move the code to production.

For self-service deployments, it’s a direct deployment without Microsoft intervention.

For more information, see Implement application lifecycle management in finance and operations apps.

Azure DevOps

For finance and operations apps development, source control is mandatory because developers are in their own developer box. Therefore, it is important that code can be shared across developer instances and that developers can always have the latest code. Also, source control is what allows you to perform branching and merging for your code. You will perform branching and merging activities to move your code between the different environments.

Consider the following process example:

  1. You might have several developers who are using developer boxes to write code.

  2. When developers are finished, they will perform a get latest by using source control, and then they will perform a build and resolve errors.

  3. When their code builds successfully, developers will perform a check-in.

  4. After all code is checked in, the code will be merged, and then it will be built.

  5. When the build is complete, the code would be promoted into a test environment, where you can perform system testing in a UAT environment.

    Note

    The code is moved through a deployable package that is created after the build is complete. The package will be applied through Lifecycle Services.

  6. You might have a UAT environment to which you can promote or deploy code for further testing.

  7. When the code is ready, you will create a service request with Microsoft so that the code can be moved to Production.

Image showing the process example from Develop to Production.

For more information, see Source control processes.