This is the classic way in which tasks are managed according to their priority;
in the form of a board. This is a customizable agile board where you can drag and drop cards around a team-recorded process.
It is noteworthy that you do not need to choose, both options are available at the same time, these are just two ways to display the same data. You can hang labels, assign to specific people, evaluate time costs, prioritize. But for me personally, the most important feature of GitLab is discussions. A pleasant interface allows you to have a live conversation, ping colleagues and refer to other entities using special characters (@, #, !, ~, etc.), insert pictures, files, emoticons, graphs, mathematical formulas, mermaid graphs, etc. It’s fun, interesting, trendy and youthful, which helps maintain healthy team relationships!
You can also have task templates (text files in the repository), for example, a typical error template might look like this:
### Expected vs Actual Behavior
### In which version it was found
### Notes
Over time, the team will most likely come to create templates that include the criteria for completing the task (definion of done, DoD).
The description of the task and discussions during the execution can be a starting point for creating documentation for the project. Sooner or later, there is a need to describe the functionality of the system. Artifacts of working on a task at the right time will help you remember why this or that decision was made. Moreover, this documentation out of the box has a connection with the code, which is especially valuable. Wondering why it works so strange? git blame -> the issue number is in the commit message -> the issue description contains the answer.
Other
Also in GitLab initially there is a wonderful opportunity to start a project wiki. Personally, I see wikis as a way to bring knowledge out of the minds of employees into text form. Because the wiki is built into GitLab, you can transparently refer to different entities like commits, issues, users, tags, and so on. It is very comfortable. Also, wiki pages keep a history of changes. They feel like regular Markdown files in a dedicated git repository. Wiki can also be perceived as a repository of project documentation. Document management is briefly discussed in the following chapters.
Milestone (milestone) is another kind of entity in GitLab, a higher level than tasks and merge requests. With its help, you can implement the organization of the latter into meaningful groups. An example of such a group would be a delivery (installation of a new software version) on a specific date.
GitLab is also capable of CI/CD, but you are unlikely to need it now if yesterday the code was stored on a development machine. I will talk about this in a nutshell in a separate chapter.
I highly recommend checking out the README. Both the smallest utility and the largest project will need README.md. The practice of documenting instructions, although it takes time, saves much more in the long run. GitLab displays the README just like the rest of Markdown, and allows you to conveniently edit and commit it directly in the Web IDE.
Note: yes, there is certainly an option to maintain a project in a private repository on GitHub, but this may be contrary to corporate security standards, there is a limit on the number of such projects. GitLab’s own deployment within an organization benefits in many ways.
Database Migrations
OK, we’ve covered the system code, but what about database objects such as tables and stored procedures? It is obvious that storing the original scripts in the database itself will sooner or later lead to problems: either they will “disperse” between the contours, or the history will be irretrievably lost, or something else like that. Database migrations come to the rescue. Migration is a transition from one database structure to another without loss of consistency. The approach to organizing migrations is limited only by the imagination and ingenuity of the developer, however, the variety of approaches known to me can be classified into:
CREATE approach – in the project code base, along with the main system code, a complete dump of all database scripts is also stored, namely, a file for each table, function, procedure, view, trigger, etc. Inside these files are CREATE statements. The same scripts are included in the distribution kit at the time of assembly (perhaps in a converted form). At the time of installation of the distribution using special software (for example, RedGate SQL Compare or SQLPackage.exe), the target database is compared with the reference database from the distribution, a difference script is generated that brings the database to the target state;
ALTER approach – in contrast to the previous approach, only the initial object creation scripts are stored here, and all changes to them are recorded as ALTER expressions. There are two ways to organize the storage of such expressions:
inside the application code, i.e. directly in the system code, and then in the binary; at startup, the system checks the version on top of which it is installed and catches up with it to the one specified in the distribution. Example in mattermost, ameditation;
externally in special files, such as XML files in the case of Liquibase (related article).
If any of these approaches are not applied from the very beginning of development, then preparatory work will be required to create an initial snapshot. In the future, it is quite convenient to work with each approach, but I personally like the CREATE approach more.