DEV Community: Felipe Tófoli

My Journey to AWS Cloud Practitioner Certification: How I Scored 967/1000!

Felipe Tófoli — Wed, 07 Feb 2024 10:00:00 +0000

Recently, I took the AWS Cloud Practitioner certification exam and scored 967 out of 1000 points. 🎉

Since I achieved a significant result, I decided to share my exam preparation strategy. 💡

In this post, you will find the study materials I used, how I organized my study routine, preparation tips, and even my strategy for answering multiple-choice questions. 💎

I hope this post can assist you on your journey to AWS Cloud Practitioner certification! ❤️

Below are all the topics covered:

📚 Study Materials
🎓 Study Routine
📅 Exam Scheduling
📝 Exam Week Preparation
📑 Exam Eve
📆 Exam Day
💎 During the Exam
✅ Results
💭 Conclusion

📚 Study Materials

Over the years, I participated in AWS projects, read pages of official documentation, and consumed various cloud computing content. However, for this certification preparation, I chose to use the following resources:

Courses 📘

Stephane Maarek’s courses were highly recommended by many friends , making it challenging not to choose him, and now I understand why!

▶️ Course: [NEW] Ultimate AWS Certified Cloud Practitioner CLF-C02

The course is very comprehensive and up-to-date. The instructor provides valuable tips about the exam and facilitates understanding of what will be asked for each AWS service.

Stephane himself states that his goal is to provide a course that helps students achieve a score in the range of 900 points. And that’s exactly what happened to me! 😃

This course includes a Practice Exam, which is quite interesting. The Practice Exams are so helpful that they deserve an exclusive mention below!

Practice Exams 📗

The practice exams created by Stephane Maarek and Abhishek Singh are very comprehensive and have a detailed explanation of correct (and incorrect) answers, along with general exam tips.

▶️ Practice Exams: 6 Practice Exams -> AWS Certified Cloud Practitioner CLF-C02

In reviews of the practice exams, I noticed some people complaining that the questions were much more difficult than the certification exam. I agree that some questions are more challenging, but if you want to score high, they are an excellent study guide.

However, after reading negative reviews about the practice exams, I decided to look for something closer to the real exam. Since English is not my first language, I was concerned about any surprises regarding the wording/vocabulary of the exam.

In the search for something closer to the real exam , I found the awsalgi website. I answered some questions to familiarize myself with the format and vocabulary of the exam, which were not much different from Stephane Maarek’s course. But it was worthwhile.

▶️ Practice Exam: AWS Certified Cloud Practitioner

My strategy with the practice exams was always the same: answer and review all questions, giving more importance to those I got wrong , doing additional research to gain more clarity about the concepts.

YouTube Channel 📺

During preparation, I referred to some videos by Neal Davis from the Digital Cloud Training channel, especially when the topic was the “6 Pillar Framework”. I found the content to be very well-explained , recommending it as a supplement to studies.

▶️ YouTube: Neal Davis -> Digital Cloud Training

🎓 Study Routine

Routine 💡

During my preparation, I allocated 1 hour per day for studies. I found that studying before starting work worked best for me because my mind was “fresh” and ready to absorb new knowledge. Additionally, it reduced the likelihood of postponing the start of studies due to any unforeseen events during the workday.

Notes ✏️

After watching each course lecture, I took notes. This time, I used a digital tool, OneNote. I like to take notes on paper, but the convenience of being able to add screenshots and perform content searches turned out to be a significant attraction.

Labs 🔨

Since I already had previous knowledge of AWS, I completed each lab only once. For those without prior knowledge, it may be interesting to do each lab twice to practice and better absorb the knowledge.

Practice Exams 📝

As previously stated, I utilized the practice exams to identify areas requiring further study, subsequently conducting additional research on these topics.

📅 Exam Scheduling

Additional Time for Non-Native English-speakers 🕕

The request for additional time must be made before scheduling the exam. The additional time is 30 minutes and can be very useful for Non-Native English-speakers.

I tried to add this extra time, and although I thought I had done it successfully, it was not added to the exam. So, I recommend checking carefully if the request for additional time was successfully registered.

In the end, the additional time was not needed (phew!). 😌 I answered the questions and reviewed all exam questions in 55 minutes. And I still had over 30 minutes left.

At Home or at the Certification Exam Center? 🏢

This question caused some doubts for me.

Initially, I scheduled the exam to be taken at home for convenience. However, after researching, I found that the examiners - the online proctors - are quite strict. I would have to remove some items from the room where I would take the exam (such as books) and also adapt my workspace , as the exam must be done on a single screen.

Unfortunately, in the week of the exam, I experienced some instability in my internet connection. Additionally, I noticed there was some noise in the room where I would take the exam (as I will explain later). Therefore, I chose to reschedule and take the exam at the certification center.

By taking the exam at a certification center, if there is any problem, they may be able to negotiate a new date in case of unforeseen events. Additionally, they probably have network contingency plans.

When taking the exam at home, I wouldn’t have this support, and if there were any problems, I would have to pay the exam costs again. Besides the frustration…

📝 Exam Week Preparation

In the 7 days before the exam, I took the Practice Exams (1 per day).

For me, the most important thing was to take them at the same time for which the exam was scheduled , and following the exam rules : using only the laptop screen and no headphones.

The strategy was useful because I got used to taking multiple-choice exams at that time, requiring less effort to stay focused , and I noticed that there was some noise at the time I had scheduled the exam.

Since I always studied with headphones, I hadn’t noticed. But by removing the headphones, I realized that the noise could be disturbing, and worse, the proctor could cancel my exam due to excessive noise.

📑 Exam Eve

I reviewed my notes.
I took a “Practice exam” at the same time as the exam to keep my brain accustomed to answering multiple-choice questions.
I created the checklist of what I would need to bring to take the exam.
And most importantly, a good night’s sleep. 😴

📆 Exam Day

I reviewed only the most important points of my notes.
I answered some (easy) Practice Exam questions, just to “wake up” my brain. I didn’t want to arrive “cold” for the exam.
I ate properly. 🍎
I reviewed the checklist of what to bring to take the exam (they ask for 2 forms of identification - in Brazil: ID/driver’s license and credit/debit card, for example). This point - reviewing the items - was crucial. Working and studying 100% from home for so long, I almost forgot to grab my glasses. 👓 The checklist saved me! 😌

💎 During the Exam

Strategy 🎯

I have some strategies for multiple-choice exams. The strategy is quite simple (and I imagine they are common), but it’s worth mentioning:

If I am sure of the answer, well… then it’s simple, I mark the option and move on to the next one;
If I’m not sure of the answer, I go by elimination until only one option remains;
If I still have doubts, I mark it for later review. When in doubt, I try not to spend too much time on the question, but I try to understand the doubt and the possible answers - many times, the exam can provide a hint about the answer in a later question , so it’s important to be attentive to make the correlation when you have the opportunity;
After applying the previous steps to all questions, I start the review;
As I said, sometimes the exam gives you input on the answers to other questions, so I review and try to apply something I learned during the exam;
When I have time, I like to review all questions:
- For those I’m sure about, I just reread the question carefully to make sure I didn’t make any silly mistakes , like ignoring something in the statement
- For those I have doubts about, it’s time to reason. If I still don’t know the answer, I mark the one that seems right and move on to the next one, without removing the review indicator;
- I go through the process until there are no more questions to review
- At a certain point, it’s not worth forcing to find an answer, it will only cause stress, so I try to let go and move on (that’s why I think it’s good to review the questions I’m sure about, so as not to lose “easy” points due to carelessness)

Breaks ⌛

If taking the exam from home, you cannot leave the computer. If you do, the exam will be canceled. As far as I know, you can’t even stop to drink water, so hydrate, eat, and go to the bathroom before starting.

At the certification center, you can take breaks to go to the bathroom and drink water. However, the clock does not pause. Eating is not allowed, so eat before starting the exam.

✅ Results

As mentioned at the beginning, I scored 967 out of 1000 possible points. And I passed! Additionally, I finished the exam in 55 minutes , with over 30 minutes remaining from the allotted time for the exam.

💭 Conclusion

I believe that preparation was crucial for the obtained result.

I enjoyed - and strongly recommend - the materials used because I learned a lot during the process.

Simulating the test was also crucial : without headphones, at the same time as the exam, using only one screen. During the exam, I was already comfortable with this scenario.

Taking the exam at the certification center made me feel at ease regarding possible unforeseen events during the exam. This allowed me to focus solely on exam preparation throughout the week, without the anxiety caused by possible external factors.

Warming up my brain on the exam day to arrive focused was very useful.

Furthermore, a good night’s sleep was essential. After all, quality sleep and adequate nutrition are things to always keep in mind, aren’t they?

That was my preparation, and I hope this post helps you! ❤️

If it helped, I would love to know, it would make me very happy! 😃

Best regards!

If you liked this post, please check more content of my personal blog: https://felipetofoli.github.io/

Code formatting for C# projects: dotnet format + GitHub Actions

Felipe Tófoli — Mon, 16 Aug 2021 12:10:05 +0000

TL;DR

Getting people to use their code review time to pinpoint code formatting issues is not productive or sustainable.

So, in this blog post, I show you:

A better approach to this code formatting verification step by using the dotnet format tool, and;
How to build a GitHub Action to make this verification in an automated and continuous way.

Why should I improve the code formatting verification in my projects?

Ensuring the consistent formatting of a project (especially those with long years of life and many people participating) is a challenge.

When the project does not use any tools to assist in this formatting process, the checks end up depending a lot on people's attention and will.

Furthermore, getting people to use their code review time to pinpoint code formatting issues (turning people into code linters) is not productive or sustainable.

How can we do it in a better way?

To apply formatting styles consistently across C# projects you can use the global dotnet tool: dotnet-format.

The dotnet-format tool relies on the .editorconfig configuration file to apply formatting to the project.

The .editorconfig is a file format for defining and maintaining consistent coding styles for multiple developers working on the same project in different editors or IDEs.

A good option is to bring the team together and clarify the settings that will be adopted, avoiding confusion.

Having a .editorconfig is useful because, with the configuration file, it is possible to register, keep the history and track the standards adopted by the team.

If you don't know how to start, you can use this .editorconfig file available in Microsoft documentation.

How to use dotnet format tool to apply code formatting

The dotnet format command can be run locally to check and fix code that does not adhere to the defined standards.

More than that, code formatting verification can be added to the CI, to automatically and continuously ensure that the desired formatting is being applied to the project.

Running in a local environment

To install dotnet-format just run the following command:

 dotnet tool install -g dotnet-format

If you just want to check that your project's formatting is according to the .editorconfig set, you can run:

 dotnet format '.\' --folder --check --verbosity diagnostic

In the above command:

--folder option indicates that the path should be treated as a folder;
--check option says this is only a verification - the project code will not be changed / formatted if deviations from the .editorconfig settings are found;
--verbosity diagnostic option is used to get the execution logs as verbose as possible.

To apply formatting to the code, simply remove the --check option from the previous command:

 dotnet format '.\' --folder --verbosity diagnostic

If you want to know more options for running dotnet format, you can refer to the official documentation.

To automate checking the code formatting, we can use GitHub Actions

The creation of a GitHub Action can be used to check the code formatting compliance with each change applied to the repository, as shown in the dotnet-format.yml file below:

Understanding the dotnet-format.yml GitHub Action

Below, step-by-step explanation of the dotnet-format.yml file:

Define the name of the GitHub Action.
```
 name: dotnet format
```
Set that the actions should be triggered by changes on the .editorconfig or C# sourcecode files (**.cs).
```
 on:
   push:
     paths:
       - "**.cs"
       - ".editorconfig"
```
As, in this case, we are dealing with a .Net Full Framework project - which is developed, compiled and published on Windows - we will keep this environment for checking the code formatting (considering the particular crlf end-of-line settings as well).
```
 jobs:
   check-format:
     runs-on: windows-latest
```
Define the section that will group all the steps performed, detailed in the next items.
```
     steps:      
```

Setup the dotnet core for later use of the dotnet CLI. Although our project is .Net Full Framework, we were able to use some global dotnet CLI tools for it.

       - name: Setup .NET Core
         uses: actions/setup-dotnet@v1
         with:
           dotnet-version: '5.0.x'

Install the dotnet-format tool for later use.

       - name: Install dotnet-format tool
         run: dotnet tool install -g dotnet-format

Checks out the code.

       - name: Check out code
         uses: actions/checkout@v2

Run the dotnet format command, for the specified path, only checking code formatting (not changing any files), and setting the maximum verbosity to get a detailed execution report.
```
       - name: Run dotnet format
         run: dotnet format '.\' --folder --check --verbosity diagnostic
```

Results

After implementing our code formatting verification step, just open a Pull Request by changing the .editorconfig file or any C# class (**.cs) to see the results of GitHub Action execution.

Failure ❌

To simulate a failure in a GitHub Action run, I added poorly formatted code to the project repository:

The check failed as the code formatting was not adherent to the .editorconfig settings, so we got some error messages about the incorrect code spacing:

...

D:\a\dotnet-full-framework-ci-sandbox\dotnet-full-framework-ci-sandbox\src\Sandbox.WebAPI\Controllers\ValuesController.cs(10,45): error WHITESPACE: Fix whitespace formatting. Insert '\s'. [D:\a\dotnet-full-framework-ci-sandbox\dotnet-full-framework-ci-sandbox]

D:\a\dotnet-full-framework-ci-sandbox\dotnet-full-framework-ci-sandbox\src\Sandbox.WebAPI\Controllers\ValuesController.cs(10,46): error WHITESPACE: Fix whitespace formatting. Insert '\s'. [D:\a\dotnet-full-framework-ci-sandbox\dotnet-full-framework-ci-sandbox]

...

The check failure was displayed on Pull Request:

You can see the complete logging of the failed execution here.

Success ✔️

We fixed the code formatting, according to what was reported by the dotnet format tool.

After the code was fixed, the check passed successfully, as we can see directly on the PR screen.

You can see the complete logging of the succeded execution here

The project

Curious about the project? This one is the repository where all the code is available:

felipetofoli / dotnet-full-framework-ci-sandbox

This repository aims to show how to create GitHub Actions to: Build and Test a .Net Full Framework Web API project; Check the code formatting (.NET / C#); Run SonarQube code static analysis.

GitHub Actions for .Net Full Framework: Build & Test

This repository aims to show how to create GitHub Actions to:

Build and Test a .Net Full Framework Web API project;
Check the code formatting (.NET / C#);
Run SonarQube code static analysis.

🇧🇷 O propósito deste repositório é apresentar a criação de GitHub Actions para um projeto de Web API .Net Full Framework, contemplando as etapas de:

Build e Teste da aplicação;
Verificação da formatação do código (.NET / C#) da aplicação;
Executar análise estática de código via SonarQube.

View on GitHub

Please, consider leaving a ⭐ in the repository it it helps you! ❤️

Conclusion 🎯

Maintaining a large codebase, ensuring its quality and that it meets the defined formatting standards, is a big challenge.

Building a flow that automatically performs these steps is very important to keep the maintenance process easier and more sustainable.

Using GitHub Actions with the dotnet format command helps achieve these goals in a simple and automated way.

GitHub Actions for .Net Full Framework: Build and Test

Felipe Tófoli — Mon, 07 Jun 2021 16:04:38 +0000

Can we create GitHub Actions to Build and Test .Net Full Framework projects?

✅ YES, we can! And I will show you how I did it.

But first, let me give you some context 💭

I recently had to deal with a legacy code base of a .Net Full Framework project.

The source code was versioned on GitHub and there was a pull request and code review flow for integrating source code into the main branch. However, there were no checks to verify the code that was being integrated, which would allow source code that did not compile, or that broke unit tests, to be included in our main branch without any alerts.

The absence of quick feedback on the health of the integrated source code created some sense of insecurity in the developers during the approval of the pull requests, since problems inserted through the addition of new code could take much longer than desired to be identified.

In order to improve our workflow, I thought about creating a CI workflow with GitHub Actions to speed up the flow of feedback during our source code integrations.

When checking the documentation of GitHub Actions, I realized that there was no template for creating a workflow for .Net Full Framework projects. And then I asked the same question at the beginning of this text:

Can we create GitHub Actions to Build and Test .Net Full Framework projects?

Throughout my research journey, I discovered some resources, both official and from the community:

The use of the above actions allowed me to create the CI pipeline for my .Net Full Framework project. I configured the CI pipeline to be triggered by each new push or pull request in the main branch, as shown in the ci.yml file below:

Understanding the created action

Below, step-by-step explanation of the ci.yml file:

Define the name of the GitHub Action.
```
 name: Build and Tests
```
Set that the actions should be triggered by push and creation of pull requests for the branch main (default branch of this project).
```
 on:  
   push:
     branches: [ main ]
   pull_request:
     branches: [ main ]
```
The build and test will be performed on a Windows operating system, because we are dealing with .Net Full Framework (which does not support other operating systems).
```
 jobs:  
   build:    
     runs-on: windows-latest
```
Define the section that will group all the steps performed, detailed in the next items.
```
     steps:      
```
Checkout the code.
```
       - uses: actions/checkout@v2
```

MSBuild setup, for later use.

       - name: Setup MSBuild
         uses: microsoft/setup-msbuild@v1

Nuget setup, for later use.

       - name: Setup NuGet
         uses: NuGet/setup-nuget@v1.0.5

VSTest setup, for later use.

       - name: Setup VSTest
         uses: darenm/Setup-VSTest@v1

Navigate to the GitHub workspace to start the restore, build and test of the application.

       - name: Navigate to Workspace
         run: cd $GITHUB_WORKSPACE

Use nuget to restore packages used by the application.

       - name: Restore Packages
         run: nuget restore Sandbox.sln

Build the solution with msbuild.exe, release mode.

       - name: Build Solution
         run: |
           msbuild.exe Sandbox.sln /p:platform="Any CPU" /p:configuration="Release"

Run the tests of the Sandbox.Tests.dll, using vstest.console.exe.

       - name: Run Tests
         run: vstest.console.exe .\tests\Sandbox.Tests\bin\Release\Sandbox.Tests.dll

Results

After we implanted our CI pipeline, just open a pull request too see the result of our implementation.

Opened PR, actions pending execution

When opening a pull request, we can now see that some checks are pending execution.

Opened PR, actions performed

After the execution of our checks, the result is already shown on the PR page. Now that the checks are ok, the Merge pull request button is highlighted.

Details of actions performed

When analyzing the checks tab, we can verify the execution step-by-step.
If there was any failure, on this page it would be possible to check which step was broken and analyze the logs to identify the error.

If you got curious to browse a page with details of the actions' executions, here you can find a successful execution, and here you find a failed execution.

The project

Are you curious about the project? This is the repository where all the source code is available:

felipetofoli / dotnet-full-framework-ci-sandbox

This repository aims to show how to create GitHub Actions to: Build and Test a .Net Full Framework Web API project; Check the code formatting (.NET / C#); Run SonarQube code static analysis.

GitHub Actions for .Net Full Framework: Build & Test

This repository aims to show how to create GitHub Actions to:

Build and Test a .Net Full Framework Web API project;
Check the code formatting (.NET / C#);
Run SonarQube code static analysis.

🇧🇷 O propósito deste repositório é apresentar a criação de GitHub Actions para um projeto de Web API .Net Full Framework, contemplando as etapas de:

Build e Teste da aplicação;
Verificação da formatação do código (.NET / C#) da aplicação;
Executar análise estática de código via SonarQube.

View on GitHub

Please, consider leaving a ⭐ in the repository it it helps you! ❤️

Conclusion 🎯

Dealing with legacy code can be very complicated, so proposing workflow improvements can help us dramatically change the reality of the project, by encouraging quick feedback and mitigating points of insecurity that harm the development team.

GitHub Actions are very useful tools for automating CI processes. Although it does not contain an initial template in the official documentation, it is possible to create workflows with GitHub Actions for .Net Full Framework, thanks to the official actions and also those created and made available by the community.

I had some work to get my CI pipeline viable, if you have any problems in the implementation of yours and want to share in the comments of this post, I will be happy to help you.

Bye! 😉 😘

…

⚠️ It is worth remembering that, before using the workflow, it is important to check if it and its dependencies are in accordance with the project policies where you want to apply them. ⚠️

[PT-BR] GitHub Actions para .Net Full Framework: Build e Teste

Felipe Tófoli — Mon, 07 Jun 2021 14:35:35 +0000

English version / Versão em inglês: "GitHub Actions for .Net Full Framework: Build and Test".

É possível criar GitHub Actions de Build e Test para projetos .Net Full Framework?

✅ Sim, é possível! E vou te mostrar como eu fiz.

Mas antes, um pouco de contexto. 💭

Recentemente tive que mexer em uma base de código legado de um projeto em .Net Full Framework.

O código estava versionado no GitHub e apresentava um fluxo de pull request e code review para integração de código na branch principal. Porém, não havia checks para verificação do código que estava sendo integrado, o que permitiria que códigos que não compilassem, ou que quebrassem os testes unitários, fossem incluídos na nossa branch principal sem nenhum alerta.

A ausência do feedback rápido sobre a saúde do código integrado gerava insegurança nos desenvolvedores durante a aprovação dos pull requests, pois problemas inseridos por meio da adição de novos códigos poderiam demorar muito mais tempo do que o desejado para serem identificados.

Com o intuito de melhorar nosso fluxo de trabalho, pensei em criar um workflow de CI com GitHub Actions para acelerar o fluxo de feedback durante as nossas integrações de código.

Ao verificar a documentação das GitHub Actions, percebi que não havia nenhum template para a criação de um fluxo voltado ao .Net Full Framework. E então fiz a mesma pergunta do início do texto:

É possível criar GitHub Actions de Build e Test para projetos .Net Full Framework?

Ao longo de minha jornada de pesquisa, descobri alguns recursos, oficiais e da comunidade:

A utilização destas actions me possibilitou criar o fluxo de CI para .Net Full Framework que é disparado a cada nova integração via push ou pull request na branch main, conforme arquivo ci.yml abaixo:

Entendendo a action criada

Abaixo, explicação passo-a-passo do arquivo ci.yml:

Nome da GitHub Action.
```
 name: Build and Tests
```
Estabelecendo que as actions devem ser executadas quando houver pushes e criação de pull requests para a branch main (branch default deste projeto).
```
 on:  
   push:
     branches: [ main ]
   pull_request:
     branches: [ main ]
```
O build e teste serão executados em um sistema operacional Windows, afinal estamos lidando com .Net Full Framework (que não oferece suporte a outros sistemas operacionais).
```
 jobs:  
   build:    
     runs-on: windows-latest
```
É definida a seção que vai agrupar todos os passos executados, detalhados nos próximos items.
```
     steps:      
```
Faz o checkout do código.
```
       - uses: actions/checkout@v2
```

Faz o setup do MSBuild para uso posterior.

       - name: Setup MSBuild
         uses: microsoft/setup-msbuild@v1

Faz o setup do Nuget para uso posterior.

       - name: Setup NuGet
         uses: NuGet/setup-nuget@v1.0.5

Faz o setup do VSTest para uso posterior.

       - name: Setup VSTest
         uses: darenm/Setup-VSTest@v1

Navega para o workspace do GitHub para iniciar o restore, build e teste da aplicação.

       - name: Navigate to Workspace
         run: cd $GITHUB_WORKSPACE

Usa o nuget para fazer restore dos pacotes utilizados pela aplicação.

       - name: Restore Packages
         run: nuget restore Sandbox.sln

Compila o código do projeto com o msbuild, em modo release.

       - name: Build Solution
         run: |
           msbuild.exe Sandbox.sln /p:platform="Any CPU" /p:configuration="Release"

Executa os testes do projeto Sandbox.Tests.dll, utilizando o vstest.console.exe.

       - name: Run Tests
         run: vstest.console.exe .\tests\Sandbox.Tests\bin\Release\Sandbox.Tests.dll

Resultados

Após a implantação do nosso CI, basta abrirmos um PR para ver o resultado da nossa implementação.

PR aberto, actions pendentes de execução

Ao abrir um PR, agora podemos ver que alguns checks estão pendentes de execução.

PR aberto, actions executadas

Após a execução dos nossos checks, o resultado já é mostrado na própria página do PR. Dá pra perceber que após verificar que os checks estão ok, o botão de Merge pull request ganhou até um destaque.

Detalhes das actions executadas

Ao analisar a aba de checks, é possível verificar passo-a-passo a execução. Se houvesse qualquer falha, nessa página seria possível verificar qual passo quebrou e analisar os logs para identificar o erro.

Se ficou curioso pra navegar em uma página com os detalhes das execuções das actions, aqui você encontra uma execução com sucesso, e aqui encontra uma execução com falhas.

Projeto completo

Ficou curioso sobre o projeto? Este aqui é o repositório onde todo o código está disponível:

felipetofoli / dotnet-full-framework-ci-sandbox

This repository aims to show how to create GitHub Actions to: Build and Test a .Net Full Framework Web API project; Check the code formatting (.NET / C#); Run SonarQube code static analysis.

GitHub Actions for .Net Full Framework: Build & Test

This repository aims to show how to create GitHub Actions to:

Build and Test a .Net Full Framework Web API project;
Check the code formatting (.NET / C#);
Run SonarQube code static analysis.

🇧🇷 O propósito deste repositório é apresentar a criação de GitHub Actions para um projeto de Web API .Net Full Framework, contemplando as etapas de:

Build e Teste da aplicação;
Verificação da formatação do código (.NET / C#) da aplicação;
Executar análise estática de código via SonarQube.

View on GitHub

Por favor, considere deixar uma ⭐ no repositório se ele te ajudar! ❤️

Conclusão 🎯

Lidar com código legado pode ser muito complicado, então propor melhorias no fluxo de trabalho pode nos ajudar a mudar drasticamente a realidade do projeto, ao incentivar o feedback rápido e mitigar pontos de insegurança que prejudicam o time de desenvolvimento.

As GitHub Actions são ferramentas muito úteis para automação de processos de CI. Apesar de não conter um template inicial na documentação oficial, é possível criar workflows com GitHub Actions para .Net Full Framework, graças às actions oficiais e também às criadas e disponibilizadas pela comunidade.

Eu tive algum trabalho para conseguir viabilizar meu pipeline de CI, se você tiver qualquer problema na implementação do seu e quiser compartilhar nos comentários deste post, ficarei feliz em poder ajudá-lo.

Um abraço! 😉 😘

…

⚠️ Vale lembrar que, antes de utilizar o workflow, é importante consultar se ele e as suas dependências estão de acordo com as políticas do projeto onde você deseja aplicá-los. ⚠️

Eventos Scrum: um relato de experiência

Felipe Tófoli — Tue, 13 Apr 2021 12:06:58 +0000

Semanas atrás, algumas pessoas do meu time que não tiveram muito contato com metodologias ágeis pediram que eu contasse um pouco sobre a aplicação do Scrum nos meus projetos anteriores, evidenciando sobre como os eventos scrum eram tocados.

Percebi que contar um pouco sobre minhas experiências positivas em times que aplicavam Scrum é uma tarefa recorrente, então decidi escrever sobre isso! 😃

Atenção!

⚠️ >>
Este texto não irá debater ou apresentar definições. Caso tenha interesse nas definições sobre os eventos citados, recomendo consultar o Scrum Guide.

E se você está começando a estudar sobre agilidade, vale consultar o Manifesto ágil.

Agilidade não se resume a Scrum.

Algumas das práticas apresentadas no texto funcionavam bem em determinados contextos. Os desafios e as escolhas que são feitas dependem muito das pessoas e do contexto.
Não existe uma solução geral (bala de prata) que funcione para todos os casos.
<< ⚠️

Eventos Scrum

Os seguintes eventos são citados no Scrum Guide e apresentados na sequência do texto:

Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective

Além dos eventos citados no Scrum Guide, será apresentada também a dinâmica de um Refinamento.

Sprint 🏃

⌛ 2 semanas (geralmente, no meu caso)
É quando o que foi planejado é executado. Para melhorar a agilidade no desenvolvimento de software costumávamos nos valer de testes automatizados (como documentação viva do código, segurança para o time fazer as alterações necessárias no código), CI/CD (facilitando o processo de deployment de software) e técnicas como pair programming.
Quando itens inesperados surgiam, o "objetivo do sprint" era utilizado como critério para decisão da priorização entre itens planejados e não planejados. Quando os itens não planejados eram adicionados ao "Sprint Backlog", algum item planejado era despriorizado, para não onerar o time.

Sprint Planning 🎯

📅 Após a retrospectiva
⌛ 2h-4h
Nas sessões de planejamento do sprint os itens refinados (aptos a serem desenvolvidos no próximo sprint) eram revisados. Os itens eram puxados pelo time de desenvolvimento, conforme a priorização estabelecida no product backlog, de acordo com o quanto o time acreditava que conseguiria produzir e se comprometer.
Para ajudar a entender, e obter certa previsibilidade, sobre o quanto um time costumava produzir durante um sprint, algumas equipes utilizavam sistemas de estimativas e técnicas: story points, tamanhos de camiseta (P, M, G), planning poker.
Ao término da sessão de planejamento do sprint, o time saía com a definição do "objetivo do sprint", que ajudaria o time a se organizar e inspecionar constantemente se as ações tomadas durante o sprint estão contribuindo para o atingimento do objetivo. A definição do objetivo sprint era muito útil para tomadas de decisão sobre a priorização dos itens no decorrer do sprint, conforme itens inesperados surgiam.

Daily Scrum 🔁

📅 Diariamente
⌛ Até 15 minutos
As dailies tinham foco em traçar o plano para as próximas 24h e avaliar se estávamos continuamente avançando em busca do objetivo do sprint. Impedimentos eram declarados e as pessoas se organizavam para superar os bloqueios ou notificar quem fosse necessário.
Quando trabalhando com times distribuídos, geralmente os times faziam a daily olhando para as tasks no board, desta forma trabalhos invisíveis eram identificados (e cadastrados no Jira), o quadro era atualizado diariamente, verificava-se quais os cards estavam parados há muito tempo, era possível notar em uma cadência diária se o time estava se aproximando do objetivo traçado no Sprint Planning, em vez de perceber isso apenas no Review.

Sprint Review 🎁

📅 No término do sprint
⌛ 1h-2h
Neste evento, apresentávamos as entregas do time e o valor que foi gerado, com foco em dar visibilidade do que foi feito e compartilhar o conhecimento entre todos. Além de fazer uma "demo", era importante contar com feedbacks e insights do time que ajudavam a definir melhorias, mudanças e os próximos passos que poderiam ser priorizados (resultando na atualização do Product Backlog).

Sprint Retrospective 📣

📅 Após o sprint review
⌛ 1h-1h30
Constituía na etapa de inspeção contínua do ciclo, uma oportunidade para notar o que estava dando certo e tínhamos interesse em continuar fazendo, e também identificar o que não estava tão legal e queríamos melhorar.
O ponto chave aqui era extrapolar os próprios pontos, e elaborar planos de ação do time que seriam acompanhados e monitorados. Os formatos variavam de conversas casuais à clássica utilização do board (utilizávamos esse board online). Tinha um pessoal que gostava de acessar esse site para aprender novos formatos de retrospectiva.

Refinamento 🔬

📅 Antes do planning
⌛ 1h
Esse evento não está listado no ScrumGuide, mas fazíamos em alguns times (principalmente para os times que precisavam de maior previsibilidade). O objetivo era refinar os itens de backlog.
O refinamento poderia indicar que o item não estava pronto para ser implementado (possivelmente devido a algum pré-requisito não mapeado que faria com que o item ficasse para o próximo sprint), ou que o item era muito grande e poderia ser dividido em mais partes. O refinamento era utilizado também como alinhamento técnico entre os engenheiros que poderiam discutir como o item seria implementado.
Para times que estimavam tarefas, era uma reunião bastante útil, pois as dúvidas eram antecipadas, evitando que as plannings ficassem muito extensas.

E você, como aplica os eventos Scrum?

Neste texto pude apresentar algumas experiências que tive aplicando os eventos Scrum no meu dia-a-dia profissional.

Você aplica de uma forma parecida? De uma forma completamente diferente? Te pareceu interessante ou errado?
Conta pra gente nos comentários! 😉

Referências

Manifesto ágil. Disponível em 16/02/2021: https://agilemanifesto.org/iso/ptbr/manifesto.html
Scrum guide. Disponível em 16/02/2021: https://www.scrumguides.org/scrum-guide.html
Frederick P. Brooks. No Silver Bullet. Disponível em 16/02/2021: http://worrydream.com/refs/Brooks-NoSilverBullet.pdf