Forem: LEDS

Scrum and agile methodology

Vinícius Machado de Souza — Tue, 08 Oct 2024 13:24:28 +0000

What is SCRUM?

Scrum is not a methodology, it is a framework. This means that Scrum won't tell you exactly what to do, but rather it will serve as a "path" to help you achieve your goal.

SCRUM has 3 basic roles:

Scrum Master: The guardian of the process. Responsible for ensuring the process runs smoothly by removing obstacles that hinder the team's productivity, organizing, and facilitating meetings. It is essential for the Scrum Master to have a deep understanding of Scrum.
Product Owner: The central figure with leadership authority over the product. Decides which products and features will be developed and in what order. It's their responsibility to communicate to the participants what the Scrum team aims to achieve in the project, and they prioritize the items in the Product Backlog.
Developers: Comprises all developers and other professionals directly involved in the product's development. They hold a role in Scrum just as important as the others, as they are responsible for turning the project into reality.

"Build the right thing. Build it the right way. Build it fast."

Scrum Principles

Empirical process control: Observation and experimentation. Through transparency, inspection, and adaptation, the process is carried out flexibly.
Self-management: Everyone is responsible for the project.
Collaboration: No one has climbed Mount Everest alone.
Value-based prioritization: Focus on delivering the most valuable items to the client.
Timebox: Exists with the purpose of setting a time frame that encompasses the entire Sprint process. Ideally, a sprint should last between 1 to 4 weeks. If for any reason a task cannot be delivered, it will be moved to the next sprint. This prevents the "student syndrome" — if you give someone 4 hours to complete a task that could be done in 1 hour, they will procrastinate for 3 hours and finish it in the last hour. Therefore, it is crucial to establish boundaries.
Iteration and increment: Scrum focuses on value delivery. Its stages repeat through sprints, and the results are incrementally based on the client's highest needs.

Basic Scrum Events

Daily Scrum
Sprint Planning
Sprint
Sprint Review
Sprint Retrospective

Daily Meetings

Every day, there are meetings of approximately 15 minutes where the team seeks to assess whether the project's progress is aligned with the Sprint Goal or if it is necessary to adapt the Sprint Backlog to meet the expected objective. The developers can structure this meeting as they see fit, and below are three questions that are not mandatory but can help guide the meeting process:

What did I do yesterday to help the team reach the sprint goal?

What will I do today to achieve the sprint goal?

Is there any impediment preventing me or the team from reaching the goal?

Product Backlog

It is a list of features to build the product, ordered by priority by the product owner. It consists of short statements that describe what the customer wants the product to do. These statements can be referred to as features or user stories. A Product Backlog consists of:

Feature or User Story: describes a desired functionality for the product.

Importance: describes how important the functionality is.

Estimate: describes how difficult it is for the team to implement.

How to create a product backlog?

Scrum doesn't tell us how to create a product backlog, only that we must have one. However, to make it easier, here are some steps for its creation:

Understand the partner's problem
Write the user stories
Relate the user stories
Prioritize the user stories
Estimate the difficulty of the user stories

This is one of the most challenging stages of a project. To do this, we can use the following techniques:

Interviews
Questionnaires
Observation
Prototyping
Investigation
User journey
Other techniques to understand the partner's/client's problem

Paper Prototyping

To help understand the user, a very good technique is Paper Prototyping (Drawing a prototype on paper). This is a brainstorming, design, creation, communication, and interface testing technique that uses paper and pen to understand user needs. This technique can be used to design websites, software, mobile devices, and hardware.

Sprints

A Sprint is a time period during which one or more items from the product backlog are selected to be developed and delivered to stakeholders in order to add value to the project. It is important for sprints to follow a predefined timebox, typically lasting between 1 to 4 weeks, depending on what is set as the final product.

What happens in each day of the Sprint

Before the start of a sprint, a sprint planning meeting is held based on what needs to be delivered as the final product. This meeting is called "sprint planning," where the sprint backlog is created. Based on the team's capacity, it is determined how many features can be fully developed within the sprint timeframe. Among the many methods that exist, one particularly interesting one that can be used for this is Planning Poker.

Planning Poker Cards

Planning Poker works as follows: the development group meets to discuss the candidate user stories to be selected for development in the current sprint. The team members each draw a card with a number that represents the difficulty they perceive in developing that feature— the lower the number, the less complex; the higher the number, the more complex. The team members who played the lowest and highest cards are selected to speak, and they seek to reach a consensus on the difficulty of that user story. This ensures that everyone is involved in the development process and also makes it more agile.

It’s important to note that these features follow the level of importance recorded by the product owner in the product backlog. At the end of the sprint, there are two additional key activities:

Sprint review: This is a meeting held right after the end of a sprint cycle, with the product owner present to validate whether the product being delivered meets their needs.

Sprint Retrospective: This is a meeting with only the development team members to evaluate the pros and cons of the development cycle in question.

Want to follow more content about agile methodologies? Follow LEDS!

Introduction to Git Merge

Heloisa Louzada B. Gomes — Fri, 20 Sep 2024 13:29:54 +0000

In this post, we will talk about an essential process in project development: the merge. Merge means "to combine," that is, the action of merging two lines of development in a project.

What is the "Head"?

Before explaining merge, it is important to understand the concept of the head. The head is a pointer that always points to the version of the code currently being worked on. When a merge is performed, the head moves to reflect the combined changes between the branches.

Merge Strategies

There are different merge strategies. Let's cover the main ones:

Fast-Forward: The simplest strategy. The system just moves the pointer forward without conflicts. This happens when, after creating a new branch, all commits and changes were made exclusively in it. Thus, when performing the merge, there are no divergences between the main branch (master) and the new branch.

Ort: This strategy is used when there are changes in both the main branch and the created branch, but in different files, without causing conflicts. Git detects that the files are in different stages but can merge the changes automatically without manual intervention.

Handling Conflicts
When a conflict occurs during the merge, the changes need to be handled manually. When using VSCode, for example, a new tab opens so you can intuitively choose how to resolve the conflicts and continue with the project.

Step by step
First, you need to be on the branch where you want to combine the changes. To do this, use the command:

git checkout [branch name]

Now, you can merge the auxiliary branch with the target branch. Use the command:

git merge [branch name]

Pratical Exemple: If you are on a branch called auxiliary_branch and you want to merge it with the master branch, execute:

git checkout master
git merge auxiliar_branch

Now the changes from auxiliary_branch are now integrated into master. Always check that you are on the correct branch before merging to avoid unwanted conflicts.

GitHub: learning about the feature called Issues☕

Vinícius Machado de Souza — Fri, 20 Sep 2024 13:07:31 +0000

What is an "issue" about?

Issues are used to track bugs and suggest improvements, providing a step-by-step control of our project. To reference a commit to an issue, simply add #[issue number] after the sentence in the commit command. Example:

git commit -m “my example #1”

To close an issue, the command used is:

git commit -m “issue closed closes #1”

To indicate that the issue has been fixed, we use the following command:

git commit -m "issue fixed fixes #1"

Step-by-step guide to using Issues:

1.Access a GitHub repository where the "Issues" feature is enabled.

2.Go to the "Issues" tab located next to "Code" to view the existing Issues.

3.Create a new Issue by clicking the "New Issue" button next to "Labels" and "Milestones."

4.Now you have access to various tools for creating an Issue, starting with the basics: a title and a detailed description of the topic being addressed.

5.On the side, there are tools to help manage Issues. First, there’s "Assignees," which refers to the people responsible for working on the Issue. Then, "Labels," which act as tags to categorize different types of Issues. "Milestone" is essentially a goal or target to be achieved. In the "Development" section, you’ll see branches and pull requests related to that Issue.

6.Now that the Issue has been created, comments can be added to allow team members to collaborate and resolve the Issue. Below, if you are the owner or a collaborator of the repository, you can close the Issue in two ways: "Close as completed," which means the issue was resolved, or "Close as not planned," meaning the issue wasn’t resolved or something else happened.

7.After creating the Issue, there are some additional options if you are the owner or a collaborator of the repository. "Lock conversation" removes the permission for other users to comment on the Issue. "Pin issue" allows you to pin up to three Issues to the top. "Transfer Issue" moves the Issue to another repository without deleting it from the current one. "Delete Issue" completely removes the Issue instead of simply closing it.

If you liked this post and it helped you better understand a GitHub feature, how about checking out other posts about Git and GitHub? Take a look at the link ahead! Forks in GitHub

Introduction to "branch"

Heloisa Louzada B. Gomes — Thu, 19 Sep 2024 14:51:41 +0000

Today, we’re going to talk about an essential concept for using Git and GitHub: branches. For this post, we’ll assume you are already familiar with the concepts of remote repository, local repository, stage, and commit; that you have already installed Git on your machine and created an account on GitHub. If you're not familiar with these concepts, check out the introductory post about Git in the following link (https://dev.to/ledscolatina/initial-introduction-to-git-and-github-4apc).

What are Branches?

A branch is essentially an independent environment where your commits are organized. Simplified, you can think of branches as parallel timelines where changes are made without interfering with others. Imagine the "multiverse" concept from Spider-Man: each version of the hero has its own timeline, and their actions do not affect the others, but when merged, they can create conflicts. Similarly, branches are separate environments where you can work without affecting the main code.

How do Branches Work?

When a project is created, it typically starts with a branch called master (or main, in the case of a clone), which is where the main code is maintained. If you want to add new features without compromising the existing functional code, the best practice is to create a new branch. This way, you can make commits and tests without affecting the main branch until everything is ready to be integrated (or even discarded, if necessary).

Creating a Branch

Let's imagine that you are starting a project in your local repository and then plan to push it to a remote repository.

When you start the project with git init, Git automatically creates a main branch for you, called master (or main).

git init

From this point, you can add files and make commits as usual. They will be recorded on the master branch, as if they were steps in a continuous timeline.

When the project is ready to be pushed to the remote repository on GitHub, we will start the step of linking the local repository to the remote one. To do this, you need to have a GitHub account and use some specific commands:

Create a new repository on your GitHub account.

Select the "<> Code" button and copy the URL of your remote repository.

In the git terminal, use the command git remote add origin [remote repository URL] to link your local repository to the remote one.

git remote add origin https://github/user/repository_name.git

To push your files to the remote repository, use a variation of the git push command. Since the repository was not cloned and we need to connect it to the remote repository, you need to specify the name of the branch you want to push, as the newly created repository does not yet have any bran ches. The command is: git push origin [branch-name].

git push origin master

Navigating Between Branches

Next, let's start a new branch. This allows you to work on a separate branch where your changes won't affect what has already been done on the main branch.

To create a new branch, use the command git branch [branch-name].

git branch new_branch

If you want to create and immediately switch to the new branch, use git checkout -b [branch-name].

git checkout -b new_branch

In this way, the files and commits added to this new branch will not be visible on the master branch, and vice versa.

To switch between branches, simply use the command git checkout [branch-name]. This is useful when you need to quickly switch between different parts of the project.

Finalizing: Merge

Suppose your modifications were successful, and now you want to integrate the new features into the main branch. For this, a powerful concept called merge comes into play. Want to know how it works? Stay tuned for the next post!

Post about merge =D

Initial introduction to Git and github

Joel Hanerth — Thu, 19 Sep 2024 14:41:57 +0000

If you're a developer or just starting to program, you've probably heard of Git and GitHub. These tools are essential in the world of software development, especially for those working in teams or on open-source projects. But what exactly are they, and why are they so important?

What is Git?

Git is a distributed version control system created by Linus Torvalds in 2005. It allows developers to track changes in code, collaborate on different features, and revert changes when necessary. Git makes team collaboration easier since each developer can have their local copy of the repository and integrate their contributions into the main project in a controlled manner.
Version control is also extremely useful for maintaining the project's history, enabling you to "go back in time" and see how the code evolved, or even revert to a previous state if something isn't working as expected.

What is GitHub?

GitHub is an online platform that hosts Git repositories. It adds a user-friendly interface and several extra features to collaborate with other developers. Besides storing repositories, GitHub offers tools such as pull requests, issues, and projects, making collaboration management and tracking bugs and new features easier.
Another important point is that GitHub has become one of the main platforms for open-source development, allowing developers worldwide to collaborate on a wide variety of projects.
With Git and GitHub, you not only have a powerful way to manage code locally but also a space to share your work and collaborate globally.

How to create a repository on GitHub:

1. Access GitHub: Log in to your GitHub account. If you don’t have an account, create one at github.com.

2. Create a new Repository:

In the upper-right corner of the screen, click the "+" icon and then click New repository.
Fill in the repository information:
- Repository name: Give your repository a name (for example, "my-project").
- Description (optional): Add a brief description of the project.
- Choose whether you want the repository to be Public or Private.
You can check the option to add a README file if you want the repository to have an initial description.

3. Create the Repository:

After filling in the details, click Create repository.
GitHub will create the repository and show the repository URL, which you will use to clone it into your Visual Studio.

Cloning the repository in Visual Studio

Now that you've created the repository on GitHub, you can clone it to your local machine and start working on it.

Steps to clone a repository in the Visual Studio terminal:

Open Visual Studio.
Open the Integrated Terminal.
Navigate to the desired folder.
Use the git clone command:
- In GitHub, copy the repository URL (HTTPS or SSH).
- In Visual Studio's terminal, type the following command:

   git clone <repository_url>

5.Result:

Git will clone the repository into the current folder, and you'll see something like this in the terminal:

   Cloning into 'my-project'...
   remote: Counting objects: 100, done.
   remote: Compressing objects: 100% (XXX/XXX), done.
   Receiving objects: 100% (XXX/XXX), done.

6.Navigate to the Cloned Repository:

Now, go to the folder of the cloned repository:

   cd my-project

YOU’RE READY TO START!

Note: If you haven’t previously configured Git on your machine, you won’t be able to clone the repository successfully. Before trying the git clone command, ensure Git is configured using the following commands in the terminal:

git config --global user.name "Your Name"
git config --global user.email "youremail@example.com"

These commands configure the global username and email in your Git environment, which will be used when making commits. If Git isn’t configured, you may encounter errors when interacting with repositories.

Let's get to work!

Now that you've cloned your repository, let's create a file, add it to version control, and explore Git's essential commands.

Creating a File and Using Basic Commands

1. Create a file:

In Visual Studio, create a new file at the root of your project, for example, a file named index.html. In the terminal, you can do this with the command:

touch index.html

Or simply create the file in the Visual Studio editor.

2. Check the Repository Status:

To see what has changed in your repository, use the git status command:

Untracked files:
  (use "git add <file>..." to include in what will be committed)
      index.html

This means Git has detected the index.html file but is not tracking it yet.

`git add` Command

3. Add Files to Version Control:

To start tracking changes to a file, use the git add command:

git add index.html

If you want to add all modified or created files, you can use:

git add .

Now the files are ready to be committed.

`git commit` Command

4. Committing Changes:

A commit records changes to the repository. To create a commit, use the command:

git commit -m "Adds index.html file"

Note: The -m flag allows you to add a descriptive message for the commit.

`git log` Command

5. Check Commit History:

To see the history of commits made in the repository, use the git log command:

git log

This is the default log option, but Git offers some useful options to simplify and customize the git log output.

Using git log --oneline

The oneline mode compresses the display of commits into a single line per commit, showing only the short hash and commit message. Command:

  git log --oneline

Using git log --graph

The git log --graph command displays the commits in a graph format, allowing you to visually see the structure of branches and merges. Command:

  git log --graph

Combining git log --graph --oneline --all

You can combine several options for a more comprehensive and simple view of the commit history. Combining --graph, --oneline, and --all (which shows commits from all branches - you can know more about branches here) is particularly useful for a clear view of the project's history. Command:

  git log --graph --oneline --all

Output (example):

  * a1b2c3d (HEAD -> master) Adds new feature
  | * 9e8f7g6 (feature) Fixes bug in feature branch
  |/
  * 5h4i3j2 Refactors code for improvements

`git checkout` Command

This command has multiple uses, but I'll cover just two:

6. Revert Changes:

If you make changes to a file and want to return to the last committed state, use the git checkout command:

git checkout index.html

This will undo changes made to index.html that haven't been committed yet.

7. View Project at a Specific Commit:

You can use the git checkout command to "look" at how the project was at a particular commit:

git checkout [commit_hash]

Pushing and Updating the Remote Repository

Now that you've made local changes, you might want to push these changes to the remote repository (GitHub) or pull the latest changes someone else made in the repository.

`git pull` Command

8. Update Local Repository:

Before pushing your changes, it's a good practice to ensure your local copy is up to date with the remote repository. To do this, use:

git pull

The git pull command brings changes from the remote repository to your local machine.

`git push` Command

9. Push Your Changes to the Remote Repository:

Now, you can push your local commits to GitHub with the git push command:

git push

This will push your changes to the master or main branch on the remote repository.

Did you like the post 🤔? Are you interested in learning more about Git features? Visit: Introduction to branch 😉

How to use Git Stash

João Ricardo Mattedi Cetto — Thu, 19 Sep 2024 14:36:23 +0000

While you work on a project in Git, you may encounter situations where you need to temporarily set aside your current work to switch branches or handle other tasks. In these cases, committing the changes of an uncompleted work isn’t always ideal. This is where the command “git stash” becomes useful. With this feature, you can save your uncommitted changes and clean up your workspace, it allows you to return to them later without losing progress. In this post, we’ll explore how to effectively use this feature and some key commands to manage your stashes.

STASH

In Git, the git stash command allows you to temporarily save changes made in your working directory without committing them. This is particularly useful when you’re working on a project but need to switch branches or handle another task without losing your uncommitted changes, which may not yet be ready to commit.

How does `git stash` work?

When you use git stash, it stores changes from both the working directory and the index (staging area), cleaning up your workspace and allowing you to switch focus to another part of the project. These changes are saved in a "stash stack," which allows you to retrieve them later when you’re ready to continue.

Basic Commands

git stash: Saves uncommitted changes in a temporary stash and cleans up the working directory.
git stash apply: Reapplies the stashed changes without removing them - from the stash stack.
git stash pop: Restores the stashed changes and removes them from the stash stack.
git stash list: Lists all saved stashes.
git stash drop [stash_id]: Removes a specific stash from the list.
git stash clear: Removes all stashes from the stack.

Using stash

Scenario:
You're working on a new feature in your project, but a bug appears and you need to switch branches to fix it. You don't want to commit your incomplete work yet, but also don't want to lose your changes.

Steps to stash:

1. Current Situation: You've made several changes to files while working on the feature-branch. Use the command git add . to add your work in progress (WIP) to the stage and, with git status you'll see that your WIP is in the stage.

$ git status
On branch feature-branch
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   teste/testando.txt

2. Save the Changes to temporarily save your work without committing it, use git stash.

$ git stash
Saved working directory and index state WIP on feature-branch: 7e9ca1a first commit

3. Fix the bug on main, commit the changes, and push them.

4. Return to Your Feature Branch once the bug fix is done with git checkout feature-branch

5. Reapply Your Stashed Changes using git stash pop.

$ git stash pop
On branch feature-branch
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   teste/testando.txt

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (8e60d99fc7d822c5c0c67b7c3f709d2085026eb2)

Obs: This command applies your saved changes back to the working directory and removes them from the stash list.

Did you enjoy the post? If you’d like to explore more Git and GitHub features, check out: Forks in GitHub

Forks in GitHub

João Ricardo Mattedi Cetto — Thu, 19 Sep 2024 13:07:55 +0000

In this post, I will introduce a important Git/GitHub feature: Forks

FORK

A fork creates an exact copy of the original repository within the user’s profile, while maintaining a link to the source repository. The primary purpose of a fork is to allow users to modify the original project, experiment with new features, or contribute to the project without directly impacting the main repository.

MAIN USES OF FORK

Collaboration in Open-Source Projects: Developers can contribute to projects without needing direct permission from the original repository;
Project Personalization: Users can make modifications to suit their specific needs while maintaining a separate repository.

HOW TO MAKE A FORK?

1. Navigate to the repository you wish to fork and click on the "Fork" option:

2. Create your fork by selecting the repository:

3. Copy the clone link of your forked repository to your local machine. You can then make changes or implement new features:

4. Clone the repository in your IDE and begin coding!!

$ git clone https://github.com/JoaoRicardoCetto/RNA-Evolutiva-C-.git
Cloning into 'RNA-Evolutiva-C-'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (3/3), 4.74 KiB | 4.74 MiB/s, done.

5. Enter the local repository, open the folder in your IDE, make your modifications, add them to the stage, commit and push it to make a pull request.

$ git commit -am "adding to the stage and committing"
warning: in the working copy of '.vscode/settings.json', LF will be replaced by CRLF the next time Git touches it
[main eedc221] adding to the stage and committing
 1 file changed, 1 insertion(+), 1 deletion(-)

6. Once you have made your changes and committed them, you can create a pull request to the main repository, suggesting your modifications to be merged into the original project.

OBS: To incorporate commits and updates from the upstream repository into your fork, use the following command: git pull upstream main.

This command fetches the latest changes from the upstream repository’s main branch and merges them into your local fork. Make sure you've previously set up the upstream repository with the correct URL:
git remote add upstream https://github.com/Owner-Name/Repository-You-Forked

This ensures that your fork stays in sync with the original project.

Did you enjoy the post? If you’d like to explore more Git and GitHub features, check out: How to use Git Stash

JIRA - Padrões de Escrita de Issues

Sofia de Alcantara — Wed, 18 Sep 2024 20:18:11 +0000

Objetivo do Documento: Detalhar como a escrita de Epics, User Stories e Subtasks no Jira devem se feita, tomando como base a documentação de Análise. Como exemplo, usaremos os Casos de Uso "Cadastrar Resolução", "Cadastrar Modalidade" e "Cadastrar Nível".*

Quais são os tipos de itens (issues) no Jira?

O Jira tem diferentes tipos de itens para categorização do trabalho. Como issues default, nessa ordem de hierarquia, temos:

Epic: Representa um grande volume de trabalho. Correspondem aos Casos de Uso.
User Story (US): Representa um requisito expresso, comumente a partir da perspectiva do usuário. Seu objetivo é articular como um recurso de software pode gerar valor para o cliente. Correspondem aos Eventos dos Casos de Uso.
Subtask: Representa a divisão mais granular do trabalho necessário para concluir um item padrão.

O que são itens vinculados?

Além da relação pai-filho entre itens, também é existem as dependências entre as tarefas. Essa associação pode ser representada com facilidade no Jira ao vincular itens. As associações prontas para uso são:

bloqueia/é bloqueado por
clona/é clonado por
duplica/é duplicado por
Relacionado a

Sendo as dependências 1 e 4 as de maior interesse. Todos os itens vinculados são exibidos em cada item. Isso torna mais fácil para as equipes navegar entre o trabalho conectado e exibir as dependências.

O que são itens pai e filho?

Pai e filho são termos que descrevem um tipo de relacionamento entre itens:

Um item pai é um item que fica um nível acima de outro item, por exemplo, uma US composta de subtarefas.
Um item filho é um item que fica um nível abaixo de outro item, por exemplo, uma US que pertence a um Epic.

O relacionamento entre pai e filho não se limita a tipos de itens específicos. Em vez disso, qualquer tipo de item pode ser um item de pai e filho. A única exceção são as subtarefas, que só podem ser um item filho, já que não há nenhum tipo de item abaixo dela na hierarquia.

Exemplo de Construção de Tarefas

Tomando como base a documentação "Especificação de Análise – Módulo Cadastro de Modalidades de Bolsas", veja os casos de usos que serão utilizados como exemplo:

ID	Caso de Uso	Eventos
UC01	Controlar Modalidade de Bolsa	Listar Modalidade, Incluir Modalidade, Criar Versão de Modalidade, Alterar Versão da Modalidade, Ativar Versão da Modalidade, Consultar Modalidade, Excluir Versão de Modalidade, Desativar Modalidade
UC02	Cadastrar Resolução	Listar Resolução, Incluir Resolução, Alterar Resolução, Consultar Resolução, Excluir Resolução
UC03	Cadastrar Nível de Bolsa	Listar Nível, Incluir Nível, Alterar Nível, Consultar Nível, Excluir Nível

Atente-se as correspondências: Casos de Usos tornam-se Epics, que são comuns a todas as equipes.
Já os Eventos dos Casos de Uso tornam-se Histórias de Usuário;

As subtarefas são específicas para cada time (FrontEnd, BackEnd, Design, Análise, etc...) e devemos utilizar a propriedade "Categorias" para indicar o time responsável pela subtarefa em questão. Veja o exemplo abaixo:

Manual de uso Immigrant - Jira

André Coelho — Mon, 03 Jun 2024 17:40:28 +0000

Visão geral

O Immigrant - Jira é uma abordagem baseada em ontologia que auxilia na identificação das necessidades de informação da organização, recuperando dados do Jira e fornecendo dados integrados que atendam às necessidades de informação.

Pré-requisitos

1- Python
2- Docker
3- Java 17

Infraestrutura

Fornece a infraestrutura base necessária para rodar o projeto.

Passo a Passo

1- Clone o repositório:

git clone https://gitlab.com/immigrant-data-driven-development/infrastructure/base-infrastructure.git
cd base-infrastructure

2- Crie um arquivo .env com o seguinte conteúdo:

DEBEZIUM_VERSION=2.0
COMPOSE_PROJECT_NAME=immigrant-cdc-infrastructure

3- Inicialize o Docker:

docker-compose up

4- Verifique a aplicação na URL: http://localhost:19000

Jira Extractor

O Jira Extractor é uma ferramenta para extrair dados do Jira. Ele utiliza a biblioteca jiraX para a extração e Apache Kafka para colocar os dados em uma fila.

Passo a Passo

1- Clone o repositório:

git clone https://gitlab.com/immigrant-data-driven-development/etl/extract/jira-extract.git
cd jira-extract

2- Crie um arquivo .env com o seguinte conteúdo:

TOPIC=application.jira.extract
SERVERS=kafka:29092
GROUP_ID=extract_jira_group

URL={url do projeto}
USERNAME={seu email}
SECRET={api token}

3- Inicialize o Docker:

 docker-compose up

4- Testando com o producer.py:

Crie e ative um ambiente virtual Python:

python -m venv env
source env/bin/activate

Instale as dependências:

pip install -r src/requirements.txt

Rode o producer:

python src/producer.py

Exemplo dos dados enviados pelo producer:

data = {  
        "url":config('URL'),
        "username": config('USERNAME'),
        "secret": config('SECRET'),        
        }

5- Verifique os tópicos gerados na URL: http://localhost:19000

SRO - Transform and Load

É o componente responsável por mapear o modelo do Jira para o banco de dados SRO.

Passo a Passo

1- Execute o serviço do Transform and Load:

Clone o repositório:

git clone https://gitlab.com/immigrant-data-driven-development/services/domain/sro.git
cd sro/webservice

Execute o serviço:

docker-compose up

mvn clean install
mvn spring-boot:run

2- Execute o Transform and Load:

Clone o repositório:

git clone https://gitlab.com/immigrant-data-driven-development/etl/transform-and-load/sro.git
cd sro

Crie um arquivo .env com o seguinte conteúdo:

KAFKA_SERVER=kafka
KAFKA_PORT=29092
DB_URL=db-pg
DB_PORT=5432
DB_NAME=sro
DB_USERNAME=postgres
DB_PASSWORD=postgres
SERVER_ETL_PORT=8091
MONGO_HOST=mongo
MONGO_DB=sro
MONGO_PORT=27017

Execute o Transform and Load:

docker-compose up

mvn clean install
mvn spring-boot:run

3- Verifique se os dados esperados estão no banco postgres gerado.

Exemplo de projeto convertido para o banco de dados SRO

Link do repositório do Immigrant
Neste repositório temos o Immigrant de forma completa.

Manual de Uso R2D2

João Marcos Rodrigues Pimentel — Mon, 03 Jun 2024 16:44:23 +0000

Este manual descreve o uso da extensão de Visual Studio Code geradora de código e documentação R2D2.

Instalação:

1- Abra o Visual Studio Code
2- Clique em extensões
3- Pesquise R2D2
4- Clique para instalar a extensão R2D2 do LEDS IFES

Como usar:

Criando o arquivo para geração:

1- Crie um arquivo de nome qualquer com a extensão .r2d2.
2- Após criar o arquivo, abra-o.
3- Aqui iniciaremos a programação da geração de código. Primeiro, definimos a configuração do projeto a ser gerado. Para fins de exemplo, vamos seguir o modelo de exemplo do Slave-One (Outro projeto do Leds). Assim, definimos as configurações do projeto:

   Configuration {
       software_name: "Slave-One" // O nome do projeto
       about: "Slave-one project example" // Uma descrição do projeto
       language: csharp-minimal-api // Escolha a linguagem em que o código será gerado
   }

Para a linguagem, temos três opções por enquanto: python, java e csharp-minimal-api.
4- Depois, definimos módulos. Assim, definimos um módulo:

   module Main {
       // Aqui ficam os componentes dos módulos
   }

5- Dentro de módulos, definimos entidades e enums:

   entity Projeto {
       nome: string
       data_inicio: date
       data_fim: date
       orcamento: decimal
       cliente: string
       patrocinador: string
       objetivo: string
       Projeto OneToMany Projeto
       Projeto OneToMany Time
       Projeto uses ProjetoStatus
   }

   enum ProjetoStatus {
       Ativo
       Cancelado
       Entregue
   }

Dentro da declaração de entidade, temos os seus atributos, como nome: string, as relações entre as classes, como Projeto OneToMany Projeto, e o Projeto uses ProjetoStatus, que indica o uso de um enum. Na declaração do Enum, apenas colocamos quais os valores do enum. E assim continuamos a declarações com quantos módulos, entidades e enums forem necessários.

Rodando R2D2 para gerar o código:

Após criar, estruturar e salvar o arquivo .r2d2, clique com o botão direito em qualquer lugar dentro do arquivo e escolha o que você deseja gerar (Na versão atual, o r2d2 gera apenas a API), como na imagem abaixo:

Após isso, as pastas e o conteúdo serão gerados na mesma pasta em que o arquivo .r2d2 se encontra.

Como utilizar o código gerado em C# no Visual Studio:

1- Abra o arquivo da solução gerada no Visual Studio: Com o Visual Studio já instalado, apenas abra a pasta do backend e abra o arquivo com o nome do seu projeto .sln.
2- (Não ocorre em todos os casos) Correção da auto relação na entidade, caso tenha alguma auto relação, entre no arquivo .cs da entidade e faça a troca do nome da entidade para o nome desejado (um nome diferente do da própria entidade para evitar conflitos no C#)

Depois disso, troque o nome da entidade também na relação dentro do ContextDb.cs:

Assim a auto relação funcionará corretamente.
3- Apenas clique para rodar o container docker e código.

Após isso é só esperar tudo compilar, que ele abrirá uma página no seu navegador com o link da API, caso apareça uma página com Hello World tudo está funcionando.

Abrindo o Swagger:

1- Já na página da API no navegador(Hello World), basta adicionar /swagger ao final do link que entraremos na tela do swagger.

Exemplo:

Link do repositório com o exemplo do Slave-One
Neste repositório temos tudo o que foi gerado seguindo este manual.

Levantando uma ASP.NET Web API em AWS ECS

Bruno Caxias — Wed, 24 Apr 2024 17:10:11 +0000

Introdução

Este artigo tem como objetivo ensinar como é possível levantar uma imagem Docker de uma Web API em ASP.NET para AWS ECS utilizando o GitLab Container Registry e o AWS Academy.

Antes de Começarmos

Para poder utilizar o ECS da AWS, antes deve-se ter um registro de uma imagem Docker do seu projeto. Nesse caso, será utilizado como exemplo um registro no repositório do GitLab, mas também é possível utilizar outros registros como o do próprio Docker (DockerHub) ou o registro do ECR da AWS. Além disso, deve-se ter um cadastro na plataforma da AWS para uso das ferramentas. No caso deste artigo, será utilizado uma conta de estudante com acesso limitado a alguns módulos. Outro ponto a se considerar é a conexão da API com o banco de dados. No exemplo fornecido, a API está conectada a um banco levantado no próprio AWS por RDS, por meio de uma string de conexão no próprio código fonte.

O Que é o ECS?

De acordo com a documentação oficial da Amazon, o ECS é um serviço totalmente gerenciado de orquestração de contêineres que ajuda a implantar, gerenciar e dimensionar facilmente aplicações conteinerizadas. Sendo assim, esse serviço se encaixa perfeitamente para as necessidades desse artigo.

Salvando a imagem Docker em um Registry

Para esse exemplo será utilizado o Container Registry do GitLab para salvar e disponibilizar a imagem do Docker contendo o projeto.

Crie um repositório com o projeto que deseja dockerizar no GitLab.
Ao criar o repositório, vá até Deploy -> Container Registry na barra lateral.

Utilize os comandos mostrados na tela principal para realizar a publicação da imagem do Docker:

docker login registry.gitlab.com
docker build -t [url do registro do projeto] .
docker push [url do registro do projeto]

Os comandos de build podem variar contendo outras tags dependendo do projeto, então é importante prestar atenção a esses cuidados.

Levantando o ECS em AWS

Iniciando o Lab

Para começar o levantamento do ECS, primeiro deve-se acessar o AWS Lab para ter acesso aos serviços.

Clique em Start Lab, assim que o símbolo de AWS ficar verde clique nele.

Criando o ECS

Após isso, na aba de pesquisa coloca-se ECS para encontrar o serviço.

Clicando um ECS a seguinte tela deve aparecer.

Crie um cluster para o serviço seguindo os passos, nesse caso será criado um cluster AWS Fargate (Sem servidor):

Insira um nome para o cluster
Selecione AWS Fargate

Criando tarefas para rodar no Cluster

Acesse Definições da tarefa na barra lateral.

Clique em Criar nova definição de tarefa.
Defina um nome para a tarefa.

Configure os requisitos de infraestrutura, nesse caso será mantido o AWS Fargate no tipo de inicialização, o sistema operacional deve ser o sistema no qual o seu Docker irá rodar, o tamanho da tarefa deve ser definido a partir dos requisitos da sua Web API (Para APIs com muita computação é aconselhável alterar os valores).

Em funções da tarefa é interessante que em Função de execução de tarefas seja selecionado um perfil com as permissões necessárias para as ações da API, ou no caso de contas de estudante (como a utilizada), seja selecionada uma opção permitida. Nesse caso, será utilizado o perfil LabRole.

Agora será o momento de configurar o container para que rode no cluster.
- Comece colocando um nome para o contêiner, o link para a imagem do Docker no repositório, mantenha a opção de Contêiner Essencial como Sim, caso as imagens do repositório sejam privadas é necessário a configuração de um Secrets Manager no AWS para autenticação e acesso a imagem no repositório.

Caso não saiba, para conseguir o link para a imagem no repositório você deve ir em Deploy -> Container Registry após ter publicado a imagem e clicar no botão de copiar ao lado do nome da imagem.

Em mapeamento de porta coloque a porta em que a API estará respondendo, no exemplo será a porta 8080. Caso queira o protocolo da aplicação pode ser alterado também (por exemplo HTTP2 para HTTPS).

No caso do exemplo o resto das opções podem ser mantidas como padrão.

Inserindo a tarefa no Cluster

Acesse o Cluster e clique em Criar na aba de Tarefa.

Em Ambiente selecione a opção Tipo de Inicialização e mantenha em Fargate.

Em Configuração de Implantação selecione Serviço. No caso da Web API, selecione a família da tarefa criada para o cluster, atribua um nome, mantenha o tipo de serviço no padrão e coloque quantas tarefas irão ser inicializadas.

Após isso, para esse exemplo pode-se manter o resto em padrão e clicar em Criar.

Acessar a API Web por IP Público

Depois de criado o serviço no cluster basta acessar o cluster e na aba services selecionar o serviço criado.

Na tela do serviço clique em Tarefas e clique na Tarefa do serviço.

Ao clicar na tarefa, na aba de Configuração será possível ver uma aba com o IP Público, por meio desse IP será possível acessar a API externamente.

Lembre-se de colocar a porta que deve ser acessada, assim como os caminhos próprios da API na URL para verificar funcionalidade.

Conclusão

Dessa forma, por meio desse artigo temos ao fim uma ASP.NET Web API Dockerizada rodando em ECS AWS. Essa publicação teve em mente detalhar e exemplificar melhor o processo de criação desse serviço utilizando imagens dos módulos. Por fim, é importante incentivar a leitura da documentação oficial do AWS assim como a busca por outros fóruns capazes de sanar dúvidas e questões relacionadas a passos específicos não elaborados suficientemente aqui.

Levantando um SQL Server RDS em AWS

Bruno Caxias — Wed, 24 Apr 2024 15:56:14 +0000

Introdução

Este artigo tem como objetivo ensinar como é possível levantar um SQL Server em RDS por meio do AWS Academy.

Antes de Começarmos

Para poder utilizar o RDS do AWS, deve-se ter um cadastro na plataforma da AWS para uso das ferramentas. No caso deste artigo, será utilizado uma conta de estudante com acesso limitado a alguns módulos.

O Que é o RDS?

De acordo com a documentação oficial da Amazon, o Amazon Relational Database Service (Amazon RDS) é um serviço da Web que facilita a configuração, operação e escalabilidade de um banco de dados relacional na Nuvem AWS. Ele fornece capacidade econômica e redimensionável para um banco de dados relacional padrão do setor e gerencia tarefas comuns de administração de banco de dados.

Levantando o RDS na AWS

Iniciando o Lab

Para começar o levantamento do ECS, primeiro deve-se acessar o AWS Lab para ter acesso aos serviços.

Clique em "Start Lab". Assim que o símbolo da AWS ficar verde, clique nele.

Criando o RDS

Após isso, na aba de pesquisa, coloca-se "RDS" para encontrar o serviço.

Clique em RDS e acesse a opção de Instâncias de banco de dados.

Clique em Criar Banco de Dados.

Na tela de criação, na aba de Escolher um método de criação de banco de dados, devido às limitações da conta utilizada, a opção de Criação Fácil é indisponível.

Em Opções de Mecanismo, selecione Microsoft SQL Server e escolha a versão que deseja utilizar para o banco. No caso do exemplo, a versão será a seguinte:

Em modelos, escolha qual a fase do projeto que deseja utilizar. Para o exemplo, será utilizado a versão gratuita.

Na aba de configurações, defina o nome, usuário e senha do banco.

As senhas podem ser salvas em AWS Secret Manager, mas aqui será utilizado um Autogerenciado.

Para o resto das configurações, pode-se manter em padrão.

Caso queira acessar seu banco externamente, é necessário fazer alterações nas configurações de Conectividade.

Nas opções, é possível vincular o banco a uma instância EC2 já existente no AWS e também é possível ativar o Acesso Público ao banco.

Após isso, pode-se criar o banco de dados e esperar o mesmo subir ao ar.

Mudando regras de acesso para o banco

Na tela de detalhes do banco, podemos ver várias informações sobre o mesmo. Em Connectivity & security, encontramos o endpoint que será a URL de acesso para o banco.

Para mudar as regras para o acesso público ao banco, é necessário acessar o firewall responsável pelo mesmo. Para isso, deve-se acessar o VPC na área de Security dentro de Connectivity & security e clicar no link do mesmo.

Ao ser redirecionado para a página de Security Groups, deve-se acessar o security group responsável pelo banco de dados.

Ao acessar o security group responsável pelo banco, pode-se ver a aba de Inbound rules e nela estarão presentes todas as regras de acesso ao banco de dados.

Para criar uma nova regra, basta clicar em Edit Inbound Rules e, na tela que aparecer, criar a nova regra.

A seguinte regra permite que qualquer IP acesse o banco, sendo necessário apenas o uso do usuário e da senha (se foram criados).

Conclusão

Dessa forma, conclui-se o tutorial com passo-a-passo e imagens para compreensão de como criar um banco de dados RDS na AWS, visando sanar possíveis dúvidas e falta de entendimento do processo. Juntamente com este documento, recomenda-se o estudo aprofundado das ferramentas do AWS, assim como a busca por outros fóruns capazes de detalhar passos não elaborados.

Forem: LEDS

Scrum and agile methodology

What is SCRUM?

Scrum Principles

Daily Meetings

Product Backlog

Sprints

Introduction to Git Merge

What is the "Head"?

Merge Strategies

GitHub: learning about the feature called Issues☕

What is an "issue" about?

Step-by-step guide to using Issues:

Introduction to "branch"

What are Branches?

How do Branches Work?

Creating a Branch

Navigating Between Branches

Finalizing: Merge

Initial introduction to Git and github

What is Git?

What is GitHub?

How to create a repository on GitHub:

Cloning the repository in Visual Studio

Creating a File and Using Basic Commands

git add Command

git commit Command

git log Command

git checkout Command

Pushing and Updating the Remote Repository

git pull Command

git push Command

How to use Git Stash

STASH

How does git stash work?

Basic Commands

Using stash

Steps to stash:

Forks in GitHub

FORK

MAIN USES OF FORK

HOW TO MAKE A FORK?

JIRA - Padrões de Escrita de Issues

Quais são os tipos de itens (issues) no Jira?

O que são itens vinculados?

O que são itens pai e filho?

Exemplo de Construção de Tarefas

Manual de uso Immigrant - Jira

Visão geral

Pré-requisitos

Infraestrutura

Passo a Passo

Jira Extractor

Passo a Passo

SRO - Transform and Load

Passo a Passo

Manual de Uso R2D2

Instalação:

Como usar:

Criando o arquivo para geração:

Rodando R2D2 para gerar o código:

Como utilizar o código gerado em C# no Visual Studio:

Abrindo o Swagger:

Exemplo:

Levantando uma ASP.NET Web API em AWS ECS

Introdução

Antes de Começarmos

O Que é o ECS?

Salvando a imagem Docker em um Registry

Levantando o ECS em AWS

Iniciando o Lab

Criando o ECS

Criando tarefas para rodar no Cluster

Inserindo a tarefa no Cluster

Acessar a API Web por IP Público

Conclusão

Levantando um SQL Server RDS em AWS

Introdução

Antes de Começarmos

O Que é o RDS?

`git add` Command

`git commit` Command

`git log` Command

`git checkout` Command

`git pull` Command

`git push` Command

How does `git stash` work?