When discussing DevOps, people can easily mistake it with the Microsoft DevOps tool that is used for project management, version control, deployment, etc. You may think “How is that even possible?!”, but the practice itself is a new concept to projects implementing the Microsoft ERP, it is something that the engineers are used to, but not the customers.
The whole idea of a practice that combines software development and IT operations and makes your project work on continuous delivery, in theory, is what every customer asks for, but in practice, you may find it difficult.
This article will provide some insides into what are the most common mistakes the Microsoft FinOps implementations have, and what should be considered when planning your project.
Planning your project
Working with Microsoft ERP FinOps, from the old to the latest version, it is quite common to find projects where people do not understand the concept of DevOps, and everything is considerate IT operations, from the development up to deployment.
As a normal practice, a technical architecture will put together resources, machine sizing, and what is needed for the technical ALM (Application Lifecycle Management) of the project. This is the moment that continuous delivery is discussed, and the strategy of the project is determined.
Considering budget and time in a short-term solution it is easier to go for the cheapest approach where you can use a resource to manually deploy across environments, bring business users to test, and have a few environments as possible. This is where most of the projects face their first issue, as the variables chosen are not considering multiple deployments across environments, and the customers will start to ask for faster deployments, will complain about resources available and the extra costs to get the work done after working hours.
The scenario above is quite common, and it is the right moment to discuss a long-term solution and the issues with the current approach. When discussing DevOps practices, keep in mind the lead time as the following:
- Fast
- Efficiency
- High quality
- Feedback
Part of a successful lead time requires better- and high-quality planning, which is a practice not quite common in implementing/ maintaining a Microsoft ERP, that is because most of the time the requirements are not very clear and the project itself has only one goal, GO-LIVE!
Although very unusual, you may find projects where the customer is familiar with the DevOps practice, in fact, some are now even including in their roles the minimum knowledge of the practice combined with Agile methodology, but most of these customers values technology and its benefits, or understands the concept of continuous delivery.
The DevOps best practices to consider in your ERP project
The ability to deliver applications and services faster than any traditional software development process is a goal in any software implementation, that is because the speed enables organisations to better serve their end-users.
Here is a list of eight best practices to use when considering the DevOps for an ERP project:
- Empowered teams
Technical resources should have the ability to change technologies or design without asking permission from someone outside the team (keeping in mind “compliance”, as it is a finance system).
- Version control
Making sure the working version of a system can be deployed to a test environment from any point in its history, using the same mechanism to deploy in test and production.
Keep change tracking of the production environment along with the release candidates.
- Deployment Automation
Control the variable using the same mechanism to deploy in test and production. Infrastructure as code.
The production environment must be a dependency, to make sure the environment being test is the same version as production will be when going live, which will prove the deployment will work as it is in a testing environment.
- Trunk based development
Merge code between branches to make it reliable.
“If you merge every day, suddenly you never get to the point where you have huge merge conflicts that are hard to resolve” – Linus Torvalds (Linux and Git creator).
- Continuous testing
Making sure all the unit tests are automated and run when committing a code to the point it can achieve a releasable outcome.
- Test Automation
When depending on manual scripts regression test validations, you can generate a human error, but also it makes it slow, low-quality, expensive, unreliable, fragile and the results are hard to understand.
Automation can be used to stress test and validate everything that is needed for data migration, system performance, component performance, acceptance, etc. Use automation tools to be repeatable and reliable and use people to explore and evaluate mix messaged in complex situations.
- Shift left on security
It is a way to short the time of deployment while shifting to the left the learning curve (From commit to releasing outcome).
- Monitoring
Determinate when the system has a problem before users complaining (measurements).
Finding the right DevOps tool
DevOps practices rely on effective tools to help teams rapidly and reliably deploy. It should help in automating manual tasks, manage complex environments at scale, and keep the engineers in control of high velocity.
Finding the right tool can be a challenge, but not very much for Microsoft ERP, as JIRA and Microsoft DevOps pretty much attend the requirements, but you can also find cheaper tools, and here it is the workflow you need to consider when choosing yours:
- Planning: It helps the project team to plan, track, and discuss the requirements in an easier way;
- Building: Build code, and automate packages;
- Testing and deploying: Automate test, deploy with CD/ CI code across environments;
- Monitoring and logging: Ensure you can monitor your environments. This stage also involves performance analysis and logging, raising smart alerts on various issues, gathering customer feedback, and so on.
In conclusion
DevOps practice can be used even in the most difficult and chaotic project, and it is not different when talking about Microsoft ERP FinOps, although not everything may work in this scenario.
In my experience, companies that are more up to date with all the technologies, are more willing to invest in the practice as they can see the long-term solution and its benefits. The companies that are still struggling with some old legacy systems and classify technology as “too expensive”, are the ones that may face more resistance. I have faced both scenarios and I believe each of them contributed to my career in using DevOps practice.
When working with a high-tech company, you will have the freedom to explore new ways to improve continuous delivery and make everyone’s life easier. You will also have the support required to trust your team as well as investing the money required. And, when working with non-tech companies you will face challenges to be within their expected budget and explain the benefits of a long-term solution that is not easily foreseen.
Article written by Ellen Candil, Head of Development
