Periodic Solution Cleanup

Staram się automatyzować wiele rzeczy. Build skrypt przechodzący lokalnie i na serverze po każdym commit’ie to podstawa. Można to w prosty sposób zrobić. Jest jednak część rzeczy, które są zbyt trudne do automatyzacji, albo po prostu nie da się ich zautomatyzować.

daily cleanup

Wymyśliłem więc, że potrzebuję listę rzeczy, które trzeba co jakiś czas wykonać, aby nic nas nie zaskoczyło podczas sesji testowej lub przed „Releasem”. Później wyewoluowało to w przypominajkę w Outlooku z pełną listą kroków do wykonania. Aktualnie przypominajke mamy dla całego teamu co 2 tygodnie.

Co jest w takiej liście:

To keep clean rules like ReSpeller (which cannot be automated or it is too time consuming) we need to maintain some rules semi-automated or manual. So every 2 weeks responsible person will run the following task (can be also found in my calendar):

@all

  • Delete all branches that are not needed anymore (ie. from old PR)

@Krzysztof Morcinek:

  • Remove all unused „usings”, https://dzienwpracy.wordpress.com/2016/08/17/okazjonalne-regularne-czyszczenie-kodu-resharperem/
  • Adjust namespaces
  • Search all “null” in solution and check how to rewrite them
  • Check if there are any TODOs without owner
  • Update all Nugets (the reason for this is to not spend time on other days to update libraries (and not even think about it)

    ○ Nugets that should not be udpated: SpecFlow

  • Clean build – fresh clone of repo (develop branch) into new folder, run build (not needed every time)
  • Check if on newest ‚develop’ can be run build script on SpecFlow VM

@Dariusz Wenderlich:

  • Verify if no misspelled words are in solution (ReSpeller)

Taka sama lista jest w OneNote (trzeba ją synchronizować).

We wcześniejszym projekcie miałem też punkt o tym, żeby puścić „test integracyjny”. Taki test nie był do końca wyizolowany. Trzeba było dopilnować kilku rzeczy, odpalić UI i rozpocząć automatyczny import trwający kilka godzin, a w tym czasie było się zblokowanym na uruchamianie aplikacji. Jeśli wydaje Wam się, że to słabe podejście to osobiście uważam, że doprowadzenie do takiego stanu to był już krok do przodu. Błędy znajdowaliśmy szybciej albo była pewność, że ich nie ma.

Po kilku miesiącach krok po kroku przy okazji innych tasków udało się ten „test integracyjny” w całości wyizolować i był już regularnie wykonywany na serwerze CI. Opuścił listę Periodic Solution Cleanup.

To tylko jeden z wielu przykładów, ponieważ ta lista jest dobrym miejscem na szukanie czasochłonnych aktywności, które można w całości zautomatyzować.

8 Comments on “Periodic Solution Cleanup

  1. Podoba mi się ten krok:

    @all

    Delete all branches that are not needed anymore (ie. from old PR)

  2. Do tych kroków można napisać automat (uważam):

    Search all “null” in solution and check how to rewrite them – testy konwencji – nie blokują builda ale informują e-mailem o wszystkich takich miejscach

    Check if there are any TODOs without owner – testy konwencji – nie blokują builda ale informują e-mailem o wszystkich takich miejscach

    Update all Nugets (the reason for this is to not spend time on other days to update libraries (and not even think about it) – sofcik (wtyczka do VS) – chociaż automatyczny update nugetów bez sprawdzenia zmian w kolejnych wersjach może narobić biedy

    Nugets that should not be udpated: SpecFlow

    • @Teo Vincent
      apropos nulli – to jeszcze nie zostały w całości wyrugowane więc dostawałbym te same miejsca ciągle w mailach. Jeszcze trochę czasu zanim ten temat będzie mógł być w całości dopięty.

      apropos TODOs – to jest fajny przykład i to dorzucę do testów CodeConventionTests, póki co mam jeden. Nie przyszło mi do głowy że warningi (to gdzie by się wywaliły testy konvencji) można potraktować mailem. Myślałem o tym dotychczas jako failujący build – warte rozważenia te maile.
      Masz to może jakoś rozwiązane w TFS?

      apropos NuGets – może narobić problemów, więc podbijam i od razu testuję czy śmigaja wszystkie testy. Gdy w poprzednim projekcie część rzeczy trwała godziny i były też testy Selenium to wolałem rzadko podbijać i od razu wszystko lokalnie sprawdzić (tzn puścić testy na noc).

    • apropos TODOs – nie mam tego ogarniętego w TFS – dopiera jak przeczytałem Twój wpis to mi coś takiego w głowie się pojawiło, nie mniej jednak TFS potrafi wysyłać e-maile do delikwenta który zepsuł dany krok builda, więc wyobrażam sobie, że można zrobić step CodeConventionTests, trochę pogrzebać w ustawieniach TFS i e-maile będą przychodziły

  3. Jeśli chodzi o kwestię TODO to w naszym projekcie wprowadziliśmy dwie rzeczy:
    1) Snippet resharpa’a który wprowadza pewien standard wpisywania TODO. Piszemy „td” co jest rozwijane na następującej formy:

    // TODO:TO_USER:JIRATICKET (FROM_USER:DATE) MESSAGE

    Resharper pozwala w snippetach ustawić macro które automatycznie ustawi pola FROM_USER oraz DATE. W ten sposób wszystkie TODO są ustandaryzowane, widać jak długo „gniją” w kodzie oraz dodatkowo wymusza to na delikwencje założenie zadania w JIRA w ramach którego zostanie zrealizowane to TODO.

    2) TODO Explorer – kolejna przydatna rzecz od Resharpera. Pozwala zdefiniować Regex do parsowania TODO dzięki czemu można łatwo odfiltrować w TODO Explorer TODO przypisane do konkretnet osoby oraz te które są nieprzypisane do nikogo. Teraz przed każdym wdrożeniem każdy widzi co jeszcze musi sprzątnąć. Jeśli nie ma zamiaru tego poprawiać (zakładam że ma ważny ku temu powód) to takie TODO się usuwa, bo wiadomo że nigdy nie zostanie zrealizowane a wprowadza tylko zamieszanie.

    https://www.jetbrains.com/help/resharper/Reference__Windows__To-do_Explorer.html

    Jeśli chodzi o dodatkowe checki jakości

    1) Skrpypt powershellowy który weryfikuje encodowanie wszystkich plików. Czasami VS/Resharper potrafi założyć plik który nie jest UTF-8 co psuje builda na TC. Skrypt zapięty po checkinie na TC. Od razu widać o który plik chodzi

    2) Skrypt wyszukujący pliki w katalogu z projektem a nie wpięte z csproj. Takie pliki wprowadzają zamęt, a w przypadku *cshtml może objawić się niespodzianką na produkcji. Możliwe że w przypadku nowych „csproj” to sie nie sprawdzi. Skrypt odpalany od czasu do czasu lokalnie.

    3) Ustawiona reguła w R# która raportuje na czerwono kod, który jest nieużywany. Po co komu taki kod?

  4. Pingback: dotnetomaniak.pl