Sonar Quality Gate

Technical Committee
#1

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

#2

Hi Łukasz,

This is great news. I have a comment, there is one problem that can be present each time we will add new classes with @EqualsAndHashCode annotation. Sonar shows that some number of conditions are not covered by tests. We don’t want to write many unit tests for equals and hashCode methods. But maybe we can use some tools like EqualsVerifier so new code can pass Quality Gate and overall coverage would increase as well?

Best regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Tue, Nov 28, 2017 at 1:18 PM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wMMq2WP0M8vPwktBKi3UAUdTo47z7LxJ8U%2Bou9mC550g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com
#3

Hi Łukasz,

is it possible to have some info about why this quality gate build failed in build details?

Regards,

Mateusz


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Tue, Nov 28, 2017 at 6:30 PM, Paweł Albecki palbecki@soldevelo.com wrote:

Hi Łukasz,

This is great news. I have a comment, there is one problem that can be present each time we will add new classes with @EqualsAndHashCode annotation. Sonar shows that some number of conditions are not covered by tests. We don’t want to write many unit tests for equals and hashCode methods. But maybe we can use some tools like EqualsVerifier so new code can pass Quality Gate and overall coverage would increase as well?

Best regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAJzpf%3DODU8XH%3DqRvwUQCuxQDpttiBxNv9fQ6pDmF0aJoQpUBQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

On Tue, Nov 28, 2017 at 1:18 PM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wMMq2WP0M8vPwktBKi3UAUdTo47z7LxJ8U%2Bou9mC550g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com
#4

Paweł Albecki: If a developer add some part of codes (even by adding annotations), those codes should be checked if work properly. I understand that methods like setters, getters, equals, hashCode will probably be implemented correctly but still this is a code that should be tested. I think using the library that you present could be a good way to achieve this.

Mateusz Kwiatkowski: Yes it is possible to add this information but because this is a custom code, each time when we will modify sonar conditions list we will have to update each sonar build on CI. Also in slack message there is a link to sonar results. In my opinion for now we should simple use the link from the slack message.


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Tue, Nov 28, 2017 at 6:42 PM, Mateusz Kwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi Łukasz,

is it possible to have some info about why this quality gate build failed in build details?

Regards,

Mateusz

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

On Tue, Nov 28, 2017 at 6:30 PM, Paweł Albecki palbecki@soldevelo.com wrote:

Hi Łukasz,

This is great news. I have a comment, there is one problem that can be present each time we will add new classes with @EqualsAndHashCode annotation. Sonar shows that some number of conditions are not covered by tests. We don’t want to write many unit tests for equals and hashCode methods. But maybe we can use some tools like EqualsVerifier so new code can pass Quality Gate and overall coverage would increase as well?

Best regards,

Paweł

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAJzpf%3DODU8XH%3DqRvwUQCuxQDpttiBxNv9fQ6pDmF0aJoQpUBQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

On Tue, Nov 28, 2017 at 1:18 PM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53wMMq2WP0M8vPwktBKi3UAUdTo47z7LxJ8U%2Bou9mC550g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com
#5


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

After I disabled cross project check for code duplication I found out that some services still have some code duplication:

OpenLMIS Fulfillment: 1%
OpenLMIS Reference Data Service: 0.7%
OpenLMIS Stock Management Service: 0.2%

I think it would be good to add new condition to quality date:

Duplicated Lines (%) is less than 5%

What do you think about that?

#6

I think that’s fine, but if I understand you correctly, all of our services are passing this criteria with ease at the moment, since the highest value is 1%? Shouldn’t we target a lower gate in that case?

Regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Wed, Nov 29, 2017 at 10:23 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53yOBnxd43v0pOM-p0uQPj9ZTEUnOJS%2BvBzrnGbKVaodWA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

–

After I disabled cross project check for code duplication I found out that some services still have some code duplication:

OpenLMIS Fulfillment: 1%
OpenLMIS Reference Data Service: 0.7%
OpenLMIS Stock Management Service: 0.2%

I think it would be good to add new condition to quality date:

Duplicated Lines (%) is less than 5%

What do you think about that?

Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875
#7

Yes all of services should pass this criteria. In the best scenario this condition should be set to 0% because we don’t want to have duplication in the given service. Now I think maybe it would be better to set it to 0% instead of 5%.


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Wed, Nov 29, 2017 at 10:57 AM, Paweł Gesek pgesek@soldevelo.com wrote:

I think that’s fine, but if I understand you correctly, all of our services are passing this criteria with ease at the moment, since the highest value is 1%? Shouldn’t we target a lower gate in that case?

Regards,

Paweł

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

On Wed, Nov 29, 2017 at 10:23 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53yOBnxd43v0pOM-p0uQPj9ZTEUnOJS%2BvBzrnGbKVaodWA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875

–

After I disabled cross project check for code duplication I found out that some services still have some code duplication:

OpenLMIS Fulfillment: 1%
OpenLMIS Reference Data Service: 0.7%
OpenLMIS Stock Management Service: 0.2%

I think it would be good to add new condition to quality date:

Duplicated Lines (%) is less than 5%

What do you think about that?

#8

I discovered that we have two Sonar Quality Gate profiles:

  1. SonarQube way with Metrics
  • Coverage on New Code
  • New Bugs
  • New Vulnerabilities
  • Technical Debt Ratio on New Code
  • New test coverage with Metrics
  • Coverage on New Code
  • Unit Test Duration
    The first one was used everywhere except Referencedata service. I already changed this so configuration for all services is consistent.

It leaves a gap. We don’t use metric for unit test duration. In New test coverage it is set to 15ms. I doubt that this is correct setting for now as in every service we have many tests that wouldn’t pass (mainly because of rest template and IO tests).

Thoughts?


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Wed, Nov 29, 2017 at 10:59 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Yes all of services should pass this criteria. In the best scenario this condition should be set to 0% because we don’t want to have duplication in the given service. Now I think maybe it would be better to set it to 0% instead of 5%.


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53z8zNzX1ky3X85_BEUsRx0dEpQQ-W63bCAG9Q6x_3ZUGg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

–

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

On Wed, Nov 29, 2017 at 10:57 AM, Paweł Gesek pgesek@soldevelo.com wrote:

I think that’s fine, but if I understand you correctly, all of our services are passing this criteria with ease at the moment, since the highest value is 1%? Shouldn’t we target a lower gate in that case?

Regards,

Paweł

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

On Wed, Nov 29, 2017 at 10:23 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53yOBnxd43v0pOM-p0uQPj9ZTEUnOJS%2BvBzrnGbKVaodWA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875

–

After I disabled cross project check for code duplication I found out that some services still have some code duplication:

OpenLMIS Fulfillment: 1%
OpenLMIS Reference Data Service: 0.7%
OpenLMIS Stock Management Service: 0.2%

I think it would be good to add new condition to quality date:

Duplicated Lines (%) is less than 5%

What do you think about that?

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com
#9

0% gate seems a bit steep, I mean I’m all for DRY, but a little duplication here or there can happen. I would say anything below 1% is good enough.

Regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Wed, Nov 29, 2017 at 11:53 AM, Paweł Albecki palbecki@soldevelo.com wrote:

I discovered that we have two Sonar Quality Gate profiles:

  1. SonarQube way with Metrics
  • Coverage on New Code
  • New Bugs
  • New Vulnerabilities
  • Technical Debt Ratio on New Code
  • New test coverage with Metrics
  • Coverage on New Code
  • Unit Test Duration
    The first one was used everywhere except Referencedata service. I already changed this so configuration for all services is consistent.

It leaves a gap. We don’t use metric for unit test duration. In New test coverage it is set to 15ms. I doubt that this is correct setting for now as in every service we have many tests that wouldn’t pass (mainly because of rest template and IO tests).

Thoughts?


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

On Wed, Nov 29, 2017 at 10:59 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Yes all of services should pass this criteria. In the best scenario this condition should be set to 0% because we don’t want to have duplication in the given service. Now I think maybe it would be better to set it to 0% instead of 5%.


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53z8zNzX1ky3X85_BEUsRx0dEpQQ-W63bCAG9Q6x_3ZUGg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com

–

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

On Wed, Nov 29, 2017 at 10:57 AM, Paweł Gesek pgesek@soldevelo.com wrote:

I think that’s fine, but if I understand you correctly, all of our services are passing this criteria with ease at the moment, since the highest value is 1%? Shouldn’t we target a lower gate in that case?

Regards,

Paweł

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

On Wed, Nov 29, 2017 at 10:23 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53yOBnxd43v0pOM-p0uQPj9ZTEUnOJS%2BvBzrnGbKVaodWA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875

–

After I disabled cross project check for code duplication I found out that some services still have some code duplication:

OpenLMIS Fulfillment: 1%
OpenLMIS Reference Data Service: 0.7%
OpenLMIS Stock Management Service: 0.2%

I think it would be good to add new condition to quality date:

Duplicated Lines (%) is less than 5%

What do you think about that?

Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875
#10

Hi all,

I want to revive this discussion and ask simple question: is it a good idea to restrict our quality gate a bit? On our Learning Session we agreed that the gate should fail on any new code smell, if we won’t be fixing them we can always remove issue directly from the Sonar. Now when we are introducing code smells we don’t have any info if we don’t check Sonar manually.

Regards,

Mateusz

···

On Tuesday, November 28, 2017 at 1:18:30 PM UTC+1, Łukasz Lewczyński wrote:

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

#11

Hi Mateusz,

I do not think it is the best idea to have sonar build failed just because there are some small code smells. It will be great, though, if you find a way to have some notifications for developers who introduced that smell and maybe to Slack #dev channel as well.

Best regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Mon, Feb 19, 2018 at 1:08 PM, mkwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi all,

I want to revive this discussion and ask simple question: is it a good idea to restrict our quality gate a bit? On our Learning Session we agreed that the gate should fail on any new code smell, if we won’t be fixing them we can always remove issue directly from the Sonar. Now when we are introducing code smells we don’t have any info if we don’t check Sonar manually.

Regards,

Mateusz
On Tuesday, November 28, 2017 at 1:18:30 PM UTC+1, Łukasz Lewczyński wrote:

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/202a0dc7-17d5-473e-84f5-c01b379766b0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com
#12

Hi Pawel,

I don’t think it is that bad, Sonar build does not block other whole workflow so changes will be deployed etc., than you can disable issue on Sonar and next Sonar build won’t fail, but you are right, some notification will suffice.

Regards,

Mateusz


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Mon, Feb 19, 2018 at 1:50 PM, Paweł Albecki palbecki@soldevelo.com wrote:

Hi Mateusz,

I do not think it is the best idea to have sonar build failed just because there are some small code smells. It will be great, though, if you find a way to have some notifications for developers who introduced that smell and maybe to Slack #dev channel as well.

Best regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

On Mon, Feb 19, 2018 at 1:08 PM, mkwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi all,

I want to revive this discussion and ask simple question: is it a good idea to restrict our quality gate a bit? On our Learning Session we agreed that the gate should fail on any new code smell, if we won’t be fixing them we can always remove issue directly from the Sonar. Now when we are introducing code smells we don’t have any info if we don’t check Sonar manually.

Regards,

Mateusz
On Tuesday, November 28, 2017 at 1:18:30 PM UTC+1, Łukasz Lewczyński wrote:

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/202a0dc7-17d5-473e-84f5-c01b379766b0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com
#13

+1 to breaking the build on code smells - these warnings usually have little sense if they don’t break the builds.

Regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Mon, Feb 19, 2018 at 2:16 PM, Mateusz Kwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi Pawel,

I don’t think it is that bad, Sonar build does not block other whole workflow so changes will be deployed etc., than you can disable issue on Sonar and next Sonar build won’t fail, but you are right, some notification will suffice.

Regards,

Mateusz


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAHq-FDPR%3DDVwsk_Ve93%2BVCfsReR2GUwZhk78HTdXimp%3DA56yeQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

–

On Mon, Feb 19, 2018 at 1:50 PM, Paweł Albecki palbecki@soldevelo.com wrote:

Hi Mateusz,

I do not think it is the best idea to have sonar build failed just because there are some small code smells. It will be great, though, if you find a way to have some notifications for developers who introduced that smell and maybe to Slack #dev channel as well.

Best regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

On Mon, Feb 19, 2018 at 1:08 PM, mkwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi all,

I want to revive this discussion and ask simple question: is it a good idea to restrict our quality gate a bit? On our Learning Session we agreed that the gate should fail on any new code smell, if we won’t be fixing them we can always remove issue directly from the Sonar. Now when we are introducing code smells we don’t have any info if we don’t check Sonar manually.

Regards,

Mateusz
On Tuesday, November 28, 2017 at 1:18:30 PM UTC+1, Łukasz Lewczyński wrote:

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/202a0dc7-17d5-473e-84f5-c01b379766b0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com

Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875
#14

Code smell is just tech debt. I am also for fixing them immediately as they arise but I am wondering if dealing with things like small code duplication, cyclomatic complexity or remove usage of some deprecated class is more important than deliver on time.
We also have some sonar rules that doesn’t make sense like: Annotate the interface with the @FunctionalInterface annotation. Not every interface with one method is suppose to be used as functional interface.


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Wed, Feb 21, 2018 at 10:43 AM, Paweł Gesek pgesek@soldevelo.com wrote:

+1 to breaking the build on code smells - these warnings usually have little sense if they don’t break the builds.

Regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

On Mon, Feb 19, 2018 at 2:16 PM, Mateusz Kwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi Pawel,

I don’t think it is that bad, Sonar build does not block other whole workflow so changes will be deployed etc., than you can disable issue on Sonar and next Sonar build won’t fail, but you are right, some notification will suffice.

Regards,

Mateusz


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAHq-FDPR%3DDVwsk_Ve93%2BVCfsReR2GUwZhk78HTdXimp%3DA56yeQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

–
Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875

On Mon, Feb 19, 2018 at 1:50 PM, Paweł Albecki palbecki@soldevelo.com wrote:

Hi Mateusz,

I do not think it is the best idea to have sonar build failed just because there are some small code smells. It will be great, though, if you find a way to have some notifications for developers who introduced that smell and maybe to Slack #dev channel as well.

Best regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

On Mon, Feb 19, 2018 at 1:08 PM, mkwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi all,

I want to revive this discussion and ask simple question: is it a good idea to restrict our quality gate a bit? On our Learning Session we agreed that the gate should fail on any new code smell, if we won’t be fixing them we can always remove issue directly from the Sonar. Now when we are introducing code smells we don’t have any info if we don’t check Sonar manually.

Regards,

Mateusz
On Tuesday, November 28, 2017 at 1:18:30 PM UTC+1, Łukasz Lewczyński wrote:

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/202a0dc7-17d5-473e-84f5-c01b379766b0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com
#15

If we have rules that we don’t intend to follow we should disable them, before we set the gates to fail.

The argument of sacrificing quality to achieve deadlines is a slippery slope - for example Scrum forbids it during a sprint. We all know how it goes when there is a rush towards a release, but all debt has to be paid sooner or later.

Regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Wed, Feb 21, 2018 at 11:29 AM, Paweł Albecki palbecki@soldevelo.com wrote:

Code smell is just tech debt. I am also for fixing them immediately as they arise but I am wondering if dealing with things like small code duplication, cyclomatic complexity or remove usage of some deprecated class is more important than deliver on time.
We also have some sonar rules that doesn’t make sense like: Annotate the interface with the @FunctionalInterface annotation. Not every interface with one method is suppose to be used as functional interface.


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

On Wed, Feb 21, 2018 at 10:43 AM, Paweł Gesek pgesek@soldevelo.com wrote:

+1 to breaking the build on code smells - these warnings usually have little sense if they don’t break the builds.

Regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com

On Mon, Feb 19, 2018 at 2:16 PM, Mateusz Kwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi Pawel,

I don’t think it is that bad, Sonar build does not block other whole workflow so changes will be deployed etc., than you can disable issue on Sonar and next Sonar build won’t fail, but you are right, some notification will suffice.

Regards,

Mateusz


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAHq-FDPR%3DDVwsk_Ve93%2BVCfsReR2GUwZhk78HTdXimp%3DA56yeQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

–
Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875

On Mon, Feb 19, 2018 at 1:50 PM, Paweł Albecki palbecki@soldevelo.com wrote:

Hi Mateusz,

I do not think it is the best idea to have sonar build failed just because there are some small code smells. It will be great, though, if you find a way to have some notifications for developers who introduced that smell and maybe to Slack #dev channel as well.

Best regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

On Mon, Feb 19, 2018 at 1:08 PM, mkwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi all,

I want to revive this discussion and ask simple question: is it a good idea to restrict our quality gate a bit? On our Learning Session we agreed that the gate should fail on any new code smell, if we won’t be fixing them we can always remove issue directly from the Sonar. Now when we are introducing code smells we don’t have any info if we don’t check Sonar manually.

Regards,

Mateusz
On Tuesday, November 28, 2017 at 1:18:30 PM UTC+1, Łukasz Lewczyński wrote:

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/202a0dc7-17d5-473e-84f5-c01b379766b0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com

Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875
#16

One more thing, we still don’t have quality gate for duplications. Łukasz, will you add this or I should do it?

Regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Wed, Feb 21, 2018 at 11:50 AM, Paweł Gesek pgesek@soldevelo.com wrote:

If we have rules that we don’t intend to follow we should disable them, before we set the gates to fail.

The argument of sacrificing quality to achieve deadlines is a slippery slope - for example Scrum forbids it during a sprint. We all know how it goes when there is a rush towards a release, but all debt has to be paid sooner or later.

Regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CADt-Nu1b3RKRhTAwiLDgVwPGVvbZNY%3D%3D51A__7tuPeD3iV3Mjg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

–

On Wed, Feb 21, 2018 at 11:29 AM, Paweł Albecki palbecki@soldevelo.com wrote:

Code smell is just tech debt. I am also for fixing them immediately as they arise but I am wondering if dealing with things like small code duplication, cyclomatic complexity or remove usage of some deprecated class is more important than deliver on time.
We also have some sonar rules that doesn’t make sense like: Annotate the interface with the @FunctionalInterface annotation. Not every interface with one method is suppose to be used as functional interface.


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–
Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875

On Wed, Feb 21, 2018 at 10:43 AM, Paweł Gesek pgesek@soldevelo.com wrote:

+1 to breaking the build on code smells - these warnings usually have little sense if they don’t break the builds.

Regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com

On Mon, Feb 19, 2018 at 2:16 PM, Mateusz Kwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi Pawel,

I don’t think it is that bad, Sonar build does not block other whole workflow so changes will be deployed etc., than you can disable issue on Sonar and next Sonar build won’t fail, but you are right, some notification will suffice.

Regards,

Mateusz


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAHq-FDPR%3DDVwsk_Ve93%2BVCfsReR2GUwZhk78HTdXimp%3DA56yeQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

–
Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875

On Mon, Feb 19, 2018 at 1:50 PM, Paweł Albecki palbecki@soldevelo.com wrote:

Hi Mateusz,

I do not think it is the best idea to have sonar build failed just because there are some small code smells. It will be great, though, if you find a way to have some notifications for developers who introduced that smell and maybe to Slack #dev channel as well.

Best regards,

Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

On Mon, Feb 19, 2018 at 1:08 PM, mkwiatkowski mkwiatkowski@soldevelo.com wrote:

Hi all,

I want to revive this discussion and ask simple question: is it a good idea to restrict our quality gate a bit? On our Learning Session we agreed that the gate should fail on any new code smell, if we won’t be fixing them we can always remove issue directly from the Sonar. Now when we are introducing code smells we don’t have any info if we don’t check Sonar manually.

Regards,

Mateusz
On Tuesday, November 28, 2017 at 1:18:30 PM UTC+1, Łukasz Lewczyński wrote:

Hi all,

The Sonar Quality Gate has been enabled for all core services. I had to create new Jenkins jobs (as pipeline) but I left old for now in case if I missed any configuration. I will probably remove them near the end of the sprint.

For now we use default settings for Quality Gate:

  • Coverage on New Code >= 80%
  • New Bugs == 0
  • New Vulnerabilities == 0
  • Technical Debt Ratio on New Code <= 5%
    The information about Quality Gate status for each service will be displayed on #build slack channel. In the end when you commit new changes please ensure that Quality Gate pass.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/202a0dc7-17d5-473e-84f5-c01b379766b0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

–

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com
#17


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

If we agreed to add this quality gate, feel free to add it.

  • Lukasz
#18

I think there was an agreement that 1% is not too low. I set this value for now, we can always lower it later.

  • Paweł


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Thu, Feb 22, 2018 at 2:02 PM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

–

If we agreed to add this quality gate, feel free to add it.

  • Lukasz

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com
#19

+1 for Paweł Gesek’s comments:

  • If we have rules we do not intend to follow, we should disable those.
  • When it comes to Code Smells and Sonar alerts, we should not sacrifice quality to achieve deadlines. If we let a few months go by sacrificing quality or ignoring sonar alerts, we would have tons of code smells in there. At that point, we would have no memory of all those parts of the codebase we were working on. It’s much cheaper to get alerts and fix it right away, hopefully within minutes after we write the code itself.
#20

Hi,

I’ve restricted Sonar quality gate to fail on any code smell, to get it “work” on UI I had to disable checks for:

  • trailing spaces - because of problems with License Header, we have ticket for that: OLMIS-3964,

  • using strict in JS files - we are using it in every JS file,

  • to many parameters in JS functions - the problem is with injecting more than 7 services or other parameters to controllers etc. which we can’t avoid, but we are also loosing check for number of parameters in regular functions,

  • function names should use cammelCase - we have functions like ProofOfDeliveryRepository or FacilityListController which are starting with upper case letter, we could rename them and keep original names while declaring those components (angular.module(some-module).controller(‘FacilityListController’, facilityListController))

Any opinions on this? Should we keep disabled checks or somehow resolve some them?

Best Regards,
Mateusz


SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Thu, Feb 22, 2018 at 9:12 PM, brandon.bowersox-johnson brandon.bowersox-johnson@villagereach.org wrote:

+1 for Paweł Gesek’s comments:

  • If we have rules we do not intend to follow, we should disable those.
  • When it comes to Code Smells and Sonar alerts, we should not sacrifice quality to achieve deadlines. If we let a few months go by sacrificing quality or ignoring sonar alerts, we would have tons of code smells in there. At that point, we would have no memory of all those parts of the codebase we were working on. It’s much cheaper to get alerts and fix it right away, hopefully within minutes after we write the code itself.

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/8aa75aef-c803-45ef-85e3-e78468f0f61a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.