How to convince your Dynamics NAV dev team to use Git (with slides)
Hi team!
Time is going fast, changing processes, tools and development approach around us. CI/CD, tooling, serverless, DevOps, DevSecOps, ArchOps and all these “ops” are not only buzzwords anymore. The base of them is Git. If you google “why do I need Git”, most of the articles will describe the difference between Git and other systems, the difference between centralised and decentralised/distributed version control systems, but it’s not easy to understand why do you really need to use Git when you get used to working without it. The article is dedicated to those of us who are still confused about these words (especially the “Git” word).
In Dynamics NAV world some of us still develop as years before and face the same problems: how to make fewer mistakes, how to deliver and deploy faster, how to control our code. The answer is simple: Git + automated testing. In more complicated words, you have to cover your code with automated tests, maintain the code using version control system (Git), carry out a code review, make a pipeline and provide a team with reliable tools.
If you develop without all these fresh modern stuff, you can fairly underestimate the benefits you could have with Git. And it’s not easy to convince yourself and your colleagues to start changing towards DevOps.
Your team (and probably you) may not understand why you need Git and all these stuff. You could find ideas further and be able to convince your team you are right.
Before you start
Analyse current process:
- How do you deliver the code to the production environment;
- How do you set up new environments (dev, test, sandboxes), the timing;
- How do you tackle with merge conflicts;
- How often do you face problems in the production environment (merge mistakes, break previously working code, plant new bugs, different issues);
- How much effort do you allocate on releasing new features, delivery process;
- Do you really control your code (can you roll back your code, link particular code with a task management system, track code history);
- Do you continuously improve the code, are you free to change your code to make it better;
- Do you really test your solution, do you have all the scenarios described, do you understand which code is for what. Is it simple to test the code against requirements;
- How do you guarantee the quality;
- Which part of the routine could be automated and speeded up.
Lots of question to think about. Having honest answers is the first key to start changing.
Further, I describe how I attempted to convince people around me that something seems not right and we could work better.
Presentation
History
Previously we didn’t have any roles: we developed code that every developer put his changes directly to the production database.
A time ago we changed the process and invented a new role in the team — release manager. RM was the person who is in charge of delivering new code to the production database.
Profit: less mess.
Risk: RM became a bottleneck. Also, we didn’t eliminate the risk of human mistake while releasing. The more people working with the code we have, the more human factor effect we get.
We still didn’t know what is wrong, how could we affect the existing code with the new one.
Merging issue
Who is merging, how long, is the process affected by human mistakes? RM, long, yes.
You made some work (green) and you want it to be merged into a destination database. The object in the destination database could differ from your version (blue).
Also, your colleague made his work on the same object (red).
RM made some work before producing release (black): comments, tabs, time and version list.
These black and red changes are accumulated in databases, so you have lots of differences.
Seems more complicated than it should be. You just want your changes (green) to be merged with the destination (blue).
Show a real example of those differences in your database.
How easy it should be (having Git)
You have a changeset.
You have a destination differs from your version (blue).
The result is made automatically. Easy peasy lemon squeezy.
Git provides you with the opportunity to store and track your code, you’ll be able to place the code on different databases. The one thing is to have all your code in one place (and track all changes). The process could be as on the picture below.
RM functions
RM used to provide the team with these services:
- Prepare codebase to release;
- Set up;
- Prepare email with changes/track changes in Confluence.
In other words:
- Merge text files manually (look carefully through all the changes, comments, detect what should be set and what shouldn’t, don’t forget anything..);
- Keep all files in folders;
- Set up (import, compile, sync);
- Work with Confluence, emails.
The first step is the most difficult and confusing. A developer has already prepared changes, why somebody has to prepare them again? Because somebody has to merge different changes into one database. Ok, but why developers don’t prepare the final version of the code? Because we don’t have a place to store “the final” version.
Having that place, the RM’s work could be:
- Make release from done code (take the code, put on a pre-release database, export .fob, import on release database);
- Work with Confluence, emails.
It is much easier and faster when RM doesn’t have to work with every single file from different developers, he could just take the final merged code. Also, the first step could be automated with scripts as well.
RM workload
How many systems do we have? A few:)
You started with one, then you added another one. RM have to handle 2 streams of changes. Every new system (based on Dynamics NAV) leads to rising RM’s workload.
How many personnel having higher educations should we have, in order to merge text files?
The issue is the more RM we have, the higher human risk we get. And also some changes have to be synchronized through different systems. It makes RM’s work more complicated and risky.
Code control
Could you answer these questions: who, when, according to which task changed objects? Could you find all the objects and particular code-lines were changed according to the task?
If the answer is “no”, you really need Git.
In my slide, it was a picture from well known Russian TV-program “Who?Where?When?”:)
Code control — how it could be
Prepare for the next slides:
- Create Git repo (I used Bitbucket to link Jira tickets with Git branches);
- Create a new task;
- Push “Create branch” button on the task page (or create branch having a task number in the name. For example task-1 in Jira, feature/task-1 in Bitbucket);
- Produce some changes, commit and push to the remote.
Say how the code control could be with good tools showing the pictures:
- The button “Create branch” on the task page;
- Links to branch, commit, pull-request on the task page (yes, you have to be prepared);
- Commit history on Bitbucket;
- File list in a commit;
- Code changes in the commit;
- Branch history.
The goal is to show how it’s easy to track changes with Git.
Emphasize the difference with the merge process described in the beginning.
Proactive code control — code review
You’ve just shown how to keep your code: with Git you could easily navigate your code and link it with the Jira (or different bug task management system).
But how could you affect your code before it been merged into production database?
The first possible answer is to carry out a code review.
Show a picture with comments in code from Bitbucket (Github or what you have).
The main idea — it is easier to change and discuss the code before it been merged.
The “second hand/eyes/head” could prevent bugs. It’s easier to follow and ensure code style having tooled code review. Also, you can spread pieces of knowledge in the tool.
Some ideas on why do you need code review on the link.
Actually, you don’t have Git to conduct code review, you could read more about it in the article.
Proactive code control — automated tests
What is wrong with your testing process? Do you test previously written code? How do you measure code quality? How often do you have regress?
The second possible answer (how could you affect your code before release) is having automated tests.
Ask your support team to provide the information about bug injection frequency. What is the average/max time from release to bug detecting (it is a good measure — time to bug detecting). It could be useful information for the presentation.
Having automated tests provides you with a great opportunity: detect bugs before the injected into the production database. From this point, you can measure and talk about code quality.
Show a picture of the test-tool.
Having a Git-based process, probably every developer would have different databases. The cons-argument could be probably next: with Git you would test the code on different databases without testing on a merged database.
From first glance, it is a good argument against Git. But:)
In general, we actually DO have different databases, and we test on different databases with different code and setups. So it is a way to fend off this argument.
Show this picture and ask, if everybody agrees with it: we develop than we test on the test database.
Then (after they say yes) show the screen from SQL Server MS: how many databases you really have. If you don’t have any mess, you are lucky. Maybe you can say that you often change databases without a clear understanding of how they differ from each other.
Every updating of databases doesn’t eliminate the problem than databases are different and the differences are accumulating.
Problems:
- Regress testing;
- It’s not easy to keep test DB clean (I wrote a code, moved it to test DB, it didn’t work, I changed the code in dev DB, moved again, but I missed remove my old code from test DB…);
- The timelapse between developing and updating test DB (if I was really lazy, I would move the code from dev to test right after release or never).
You (we) accumulate these problems in every test DB. So the argument that we would manually test our code in different DBs doesn’t work (especially we could run automated tests on DB having all code merged).
How do we test now
You should prepare again.
- Create a repo;
- Export files from dev DB, create a commit;
- Export files from test DB, create a commit;
- Export files from prod DB, create a commit.
So now you have 3 commits which show you the difference between the databases. Show it your team (different objects quantity, object types). Don’t forget to emphasize that you did it on 10 minutes including making coffee:)
With the difference, you don’t test your solution on the consistent database because you don’t have an answer to the question of what a consistent database is.
Show the code with comments and marks from your database. You don’t have to mark the code having Git, because Git will track the history for you. And what is in the Git-repo — that is a consistent and actual code. Without marks and history-comments.
Possible process
Sounds meaningful not to test again and again by your hand but give the work to a computer. Create your best-automated tests and they will show you again and again what is going on.
Having code and tests in one place makes you able to perform this action. It would be exhausting to make this work manually.
All you need is a repository with up to date codebase.
Speed and efficiency of automated testing
Show a picture with test tool run. The aim is to show the speed of tests. If you don’t have your own, just google them. Or show mine:) About 8 seconds for 28 scenarios!
Use the red-green-refactor cycle:
- Write a test, it is red (you don’t have a code);
- Write a code to cover the test, the test is green;
- Make your code better — refactor!
Branching
Do you remember a situation when you and your colleague had to change the same code (or coupled code) and you had somehow to deal with? Make your colleagues remember it was not easy. And you face the problem again and again.
Having a Git repository (and a development database for each developer, yes, the idea is isolation) you don’t have this problem again. Everybody has a database and a control mechanism providing you with the opportunity of updating databases. It’s easy to update/create new database having a code outside of the database. All you need is Git repo and scripts (f.e. standard PowerShell scripts, Waldo’s one is the best).
Risks
Code stopped working. The main one.
Answer: code-review and automated tests.
Release delays.
Answer: Git. RM doesn’t have to work with code again. Just take it from the repo.
Knowledge accumulation
Which practices do we use? Which common mistakes do we make? Which typical templates and solutions do we have and can we repeat?
Presentation summary
Git can provide the team with the following:
- Less manual work;
- Fewer people working with the same code;
- Code control, history;
- A good point to start the quality management process;
- Deploy actual databases when you want;
- Better and more convenient development;
- Minimise some risks.
Last advice
Hope that information will help you and your team become better.
If it wasn’t helpful in your case, don’t be sad! Just start working with Git and tests and after a while, your colleagues will see how is it cool (and you).
- Create your own Git repo;
- Start making tests;
- Store test code in the repo (just test, it’s enough);
- Store your scripts in the repo;
- Update your repo continuously.
