Skip to content

Feed aggregator

Listen, Test, Code, Design OVER Sprints, Scrums, and ScrumMasters

"Back to basics" is Scrum?I've been noticing people talk about getting "back to the basics" and then proceed to talk about Scrum roles and rituals.

This annoys me for 2 main reasons:
  1.  Scrum was never "basics" for me and I've typically been doing this longer than the person who suggests this
  2. The more important reason is that if we think about this carefully, Scrum cannot be the "basics"
"Back to basics" should be about the essence of what we are doing"Back to basics", "focusing on the fundamentals", etc. is about getting back to the essence of an activity.  I touched upon this when I was exploring the concept of doctrine but let's think about this using the frame of "basics" or "fundamentals".

If we look at the context of developing software for a purpose, as opposed to as a hobby, what is the essence of what needs to happen?
  1. You need a shared understanding of what problem the software is intended to solve.  We have learned that the best way to do this is to engage directly with the relevant situation and people.
  2. You need a shared understanding of what the solution needs to do to solve the problem.  We have learned that the best way to do this is through conversations leading to agreed examples and then iterating.
  3. You need to build the solution.  We have learned that the best way to do this is in a thoughtful, collaborative, disciplined way.
  4. You need to manage the growing complexity of the system to ensure that it continues to be easy to change.  We have learned that the best way to do this is as an ongoing exercise reflecting the best knowledge we have at each point.
A more compact version of this might be: Listen, Test, Code, Design.
If you don't get good at these basics, all your Sprints, Scrums, and ScrumMasters won't matter much.
Categories: Blogs

Measuring Business value in Agile projects

Agile World - Venkatesh Krishnamurthy - Sun, 08/24/2014 - 01:44

image

Because the first principle of the Agile Manifesto talks about delivering valuable software to the customer, many agile practitioners are constantly thoughtful of the value in each step of the software-development lifecycle.

At the thirty-thousand-foot level, value creation starts with gathering requirements and continues with backlog creation, backlog grooming, writing user stories, and development, finally ending with integration, deployment, and support. Even with knowledge of all these moving parts, it is common to see organizations only measuring value during development and ignoring the rest of the steps.

What’s the fix? During backlog creation, user stories need to be compared and contrasted in order to promote maximum value delivery. The product owner might need to use different techniques, such as T-shirt sizing, in order to better prioritize the project’s stories.

An alternate approach to measuring the business value of user stories is to use a three-dimensional metric that incorporates complexity, business value, and the ROI. Creating value can often require a change in perspective from the normal project’s tasks and functions. Thinking outside the box, identifying business value before writing the user stories is much better than writing and then trying to evaluate.

Read  the complete article about measuring business value on TechWell

Picture courtesy https://flic.kr/p/8E7Dr5

Categories: Blogs

Xebia IT Architects Innovation Day

Xebia Blog - Sat, 08/23/2014 - 18:51

Friday August 22nd was Xebia’s first Innovation Day. We spent a full day experimenting with technology. I helped organizing the day for XITA, Xebia’s IT Architects department (Hmm. Department doesn’t feel quite right to describe what we are, but anyway). Innovation days are intended to inspire as well as educate. We split up in small teams and focused on a particular technology. Below is as list of project teams:

• Docker-izing enterprise software
• Run a web application high-available across multiple CoreOS nodes using Kubernetes
• Application architecture (team 1)
• Application architecture (team 2)
• Replace Puppet with Salt
• Scale "infinitely" with Apache Mesos

In the coming weeks we will publish what we learned in separate blogs.

First Xebia Innovation Day

Categories: Companies

New Foundations 3.0 Webinar

Agile Product Owner - Sat, 08/23/2014 - 16:26

Hi,

We’ve just posted an updated introductory Webinar: SAFe Foundations: Be Agile. Scale Up. Stay Lean. at ScaledAgileFramework/foundations. “Foundations” is the free Powerpoint briefing (download from the same page) that you can use in most any context to describe SAFe to your intended audience.

In this 45 minute webinar, I walk through the Foundations PPT and describe:

  • The rationale for Agile and SAFe
  • A bit of SAFe history
  • SAFe core values
  • Business benefits enterprises have achieved with SAFe
  • Lean Thinking overview
  • A brief overview, of SAFe Team, Program, and Portfolio levels
  • Introduction to the Principles of Lean Leadership
  • Next Steps and Implementation 1-2-3 Guidance

Thanks to Jennifer Fawcett for hosting the event.

Categories: Blogs

Why Iterative Planning?

Leading Agile - Mike Cottmeyer - Fri, 08/22/2014 - 17:40

First, I would like to credit Eric Ries in his 2010 Web 2.0 speech for giving me the idea for these awesome graphics. If you have never seen the speech then I highly recommend the version found on YouTube. I have always admired people with creative slides who can capture ideas with elegant simplicity. Since my artistic ability peaked in the first grade, the images in this post demonstrate my foray into abstract expressionism and hopefully convey the point of why we in software need iterative planning.

Unknown Problem | Unknown Solution

Most software changes start life in the state of an unknown problem with an unknown solution. Iterative planning graphNow the product mangers reading this may beg to differ but, most of the time a vague idea on having the software do something is not a known problem space. Say for instance I want to allow uninsured people to buy insurance as a government subsidized rate.  Most of us can imagine that this is a huge problem space and truly we would have no idea how to make this happen.  In this case the problem space and the solution space is unknown.  In order to plan a software delivery that will solve the want above, I need to clearly understand the problem that needs to be solved.  To do this in agile software delivery we create something called a roadmap.  The roadmap is a way of breaking this big unknown problem into smaller chucks that we can estimate (“guess wrong”) as to how long it will take to implement them.  It is usually at this stage that these chunks of work are funded.

Known Problem | Unknown Solution

Now a software releasIterative planning graphe is ready to be planned with some chunk of the roadmap.  In order to do that, the problem should be fairly well known and can be broken it into pieces.  These pieces can be estimated (“guessed wrong”) and slotted into delivery iterations.  Lets say we want to allow people to log into a website and sign up for insurance.  This is a relatively well-known problem space, there are security concerns, 3rd party integrations, databases, platforms and deployments.  Maybe this will not all fit in one release, but with more elaboration and planning a reasonable release plan with a list of risks will emerge. It is usually at this stage that the guess of the size of the thing in the roadmap is known to be wrong and changes must be made to the roadmap.

Known Problem | Known Solution

Iterative planning graphFinally we are ready to plan an iteration. So take a chunk of the release plan and break it into pieces and as a team there needs to be some certainty that these pieces of work can be completed in the sprint. If there are still things that don’t have a clear solution then don’t take those in the sprint and take a spike or research item instead. It is now that the wrongness of the guess during release planning is known and adjustments can be made both to the release plan and the roadmap.

Planning and elaboration go hand in hand as items move from unknown problem -unknown solution to known problem-unknown solution to known problem – known solution.

The post Why Iterative Planning? appeared first on LeadingAgile.

Categories: Blogs

GOAT14 – Call for Speakers

Notes from a Tool User - Mark Levison - Fri, 08/22/2014 - 15:41

This year’s Gatineau Ottawa Agile Tour (#GOAT14) will take place on Monday, November 24th 2014, and Agile Pain Relief Consulting is once again a proud sponsor. Organizers are looking for engaging and inspirational speakers for this year’s conference. If you are interested in participating, please submit a proposal by completing the online form at http://confengine.com/gatineau-ottawa-agile-tour-2014. The organizing committee will select speakers based on the following criteria:

  • Learning potential for and appeal to participants
  • Practicality and usefulness/applicability of content to the workplace
  • Overall program balance Speaker’s experience and reputation
  • Interactive elements (i.e. exercises, simulations, questions…)

Deadline for proposals: Sunday September 15th at 23:59pm

About the Gatineau – Ottawa Agile Tour
The Gatineau – Ottawa Agile Tour (#GOAT14) is a full day of conferences around the theme of Agility applied to software development, but also to management, marketing, product management and other areas of today’s businesses.

Categories: Blogs

Neo4j: LOAD CSV – Handling empty columns

Mark Needham - Fri, 08/22/2014 - 14:51

A common problem that people encounter when trying to import CSV files into Neo4j using Cypher’s LOAD CSV command is how to handle empty or ‘null’ entries in said files.

For example let’s try and import the following file which has 3 columns, 1 populated, 2 empty:

$ cat /tmp/foo.csv
a,b,c
mark,,
load csv with headers from "file:/tmp/foo.csv" as row
MERGE (p:Person {a: row.a})
SET p.b = row.b, p.c = row.c
RETURN p

When we execute that query we’ll see that our Person node has properties ‘b’ and ‘c’ with no value:

==> +-----------------------------+
==> | p                           |
==> +-----------------------------+
==> | Node[5]{a:"mark",b:"",c:""} |
==> +-----------------------------+
==> 1 row
==> Nodes created: 1
==> Properties set: 3
==> Labels added: 1
==> 26 ms

That isn’t what we want – we don’t want those properties to be set unless they have a value.

TO achieve this we need to introduce a conditional when setting the ‘b’ and ‘c’ properties. We’ll assume that ‘a’ is always present as that’s the key for our Person nodes.

The following query will do what we want:

load csv with headers from "file:/tmp/foo.csv" as row
MERGE (p:Person {a: row.a})
FOREACH(ignoreMe IN CASE WHEN trim(row.b) <> "" THEN [1] ELSE [] END | SET p.b = row.b)
FOREACH(ignoreMe IN CASE WHEN trim(row.c) <> "" THEN [1] ELSE [] END | SET p.c = row.c)
RETURN p

Since there’s no if or else statements in cypher we create our own conditional statement by using FOREACH. If there’s a value in the CSV column then we’ll loop once and set the property and if not we won’t loop at all and therefore no property will be set.

==> +-------------------+
==> | p                 |
==> +-------------------+
==> | Node[4]{a:"mark"} |
==> +-------------------+
==> 1 row
==> Nodes created: 1
==> Properties set: 1
==> Labels added: 1
Categories: Blogs

You shall not pass – Control your code quality gates with a wizard – Part III

Danube - Fri, 08/22/2014 - 13:25
You shall not pass – Control your code quality gates with a wizard – Part III

If you read the previous blog post in this series, you should already have a pretty good understanding on how to design your own quality gates with our wizard. When you finish reading this one, you can call yourself a wizard too. We will design a very powerful policy consisting of quite complex quality gates. All steps are first performed within the graphical quality gate wizard. For those of you who are interested in what is going on under the hood, we will also show the corresponding snippets of the XML document which is generated by the wizard. You can safely ignore those details if you do not intend to develop your own tooling around our quality gate enforcing backend. If you play with this thought though, we will also show you how to deploy quality gates specified in our declarative language without using our graphical wizard.

Your reward – The Power Example powerexample1 You shall not pass – Control your code quality gates with a wizard – Part III

Power example with six quality gates

Before we reveal the last secrets of our wizard and the submit rule evaluation algorithm, you probably like to know the reward for joining us. The policy we are going to design consists of the following steps:

1. At least one user has to give Code-Review+2 , authors cannot approve their own commits (their votes will be ignored)

2. Code-Review -2 blocks submit

3. Verified -1 blocks submit

4. At least two CI users (belonging to Gerrit group CI-Role) have to give Verified +1 before a change can be submitted

5. Only team leads (a list of Gerrit users) can submit

6. If a file called COPYRIGHT is changed within a commit, a Gerrit group called Legal has to approve (Code-Review +2) the Gerrit change

The final policy can be downloaded from here. Please note that it will not work out of the box for you as your technical group ids for the Legal and CI groups as well as the concrete user names for team leads will differ. We will guide you step by step how you come up with a result that fits your specific situation.

Starting with something known – Gerrit’s Default Submit Policy

powerexample step1to3 You shall not pass – Control your code quality gates with a wizard – Part III

Looking at steps 1, 2 and 3, you probably realized that they are quite similar to Gerrit’s Default Submit policy. Because of that, let’s start by loading the template Default Gerrit Submit Policy. Once you see the first tab of the editor that opens, adjust name and description as shown in the screenshot below.

 You shall not pass – Control your code quality gates with a wizard – Part III

If you now switch to the Source tab (the third one), you can see the XML the wizard generated for the default policy:

 You shall not pass – Control your code quality gates with a wizard – Part III

The XML based language you can see here is enforced by our Gerrit Quality Gate backend. We believe that this language is way easier to learn than writing custom Prolog snippets (the default way of customizing Gerrit’s submit behavior). Furthermore, it exposes some features of Gerrit (like user group info) which are not exposed as Prolog facts. Our Quality Gate backend is implemented as a Gerrit plugin that contributes a custom Prolog predicate which in turn parses the XML based language and instructs Gerrit’s Prolog engine accordingly. This amount of detail is probably only relevant to you if you intend to mix your own Prolog snippets with policies generated by our wizard.

The schema describing our language can be found here. Looking at the screenshot above, you can clearly see that the XML top element GerritWorkflow contains all settings of the first tab of our wizard. You have probably spotted the attributes for name, description, enableCodeReview and enableVerification. The latter two store the info whether to present users with the ability to vote on the Code-Review/Verified categories (given appropriate permissions).

The only child elements accepted by the GerritWorkflow element are SubmitRules. You can clearly see the three submit rules of the default policy, we have covered in detail in our second blog post. Let’s examine the first submit rule named Code-Review+2-And-Verified-To-Submit. If all its voting conditions are satisfied, it will be evaluated to allow, making submit possible if no other rule gets evaluated to block. As this rule has not specified any value for its actionIfNotSatisfied attribute, it will evaluate to ignore if not all its voting conditions are satisfied. Talking about voting conditions, you can see two VotingCondition child elements. The first one is satisfied if somebody gave Code-Review +2, the second one if somebody gave Verified +1. The second SubmitRule element maps directly to step 2 of our power example ( Code-Review -2 blocks submit), the third one directly to step 3 (Verified -1 blocks submit).

Ignore author votes by introducing a voting filter

powerexample step1 You shall not pass – Control your code quality gates with a wizard – Part III

Let’s modify the first submit rule that it matches the first step of our power example policy:

“ At least one user has to give Code-Review+2 , authors cannot approve their own commits (their votes will be ignored)”

For this, we first switch to the second tab of our wizard (Submit Rules) and double click on the first submit rule. Right after, we double click on the first voting condition (Code-Review) and check the Ignore author votes checkbox in the dialog that opens, see screenshot below.

 You shall not pass – Control your code quality gates with a wizard – Part III

Once we save this change (press Finish in the two dialogs) and switch back to the Source tab, we can see that the XML of the first submit rule has changed:

 You shall not pass – Control your code quality gates with a wizard – Part III

The first VotingCondition element now has a VoteAuthorFilter child element. This one has its ignoreAuthorVotes attributes set to true, which in turn will make sure that only votes of non authors will be taken under consideration when this voting condition gets evaluated. You also notice the ignoreNonAuthorVotes attribute. With that one, it would be possible to turn the condition around (if set to true) and ignore all but the author’s votes. If both attributes are set to true, all votes will be ignored. Voting conditions always apply to the latest change set of the Gerrit change in question.

Adding a group filter to the verified voting condition

powerexample step4 You shall not pass – Control your code quality gates with a wizard – Part III

Now that we have realized step 1 of our power example and step 2 and 3 could be just left unmodified from the default policy, let’s focus on step 4:

“At least two CI users (belonging to Gerrit group CI-Role) have to give Verified +1 before a change can be submitted”.

This can be achieved by modifying the second voting condition (Verified) of the first submit rule. This time, we do not ignore Verified votes from authors (we could by just checking the same box again) but by adding a group and a count filter.

 You shall not pass – Control your code quality gates with a wizard – Part III

Like shown in the screenshot above, enter 2 into the Vote Count Min field and add the Gerrit group of your choice that represents your CI users. The wizard allows you to select TeamForge groups, TeamForge project roles and internal Gerrit groups.

If we finish the dialogs and switch back to the Source tab, we can see that the second voting condition of our first submit rule has changed:

 You shall not pass – Control your code quality gates with a wizard – Part III

Two filters appeared, one VoteVoterFilter and one VoteCountingFilter. The first one makes sure that only votes casted by the CI_ROLE (we chose TeamForge project role role1086 here) will be recognized when evaluating the surrounding VotingCondition.

The second filter is a counting filter. Counting and summing filters are applied after all other filters within the same VotingCondition have been already applied. In our case, it will be applied after all votes which

a) do not fit into voting category Verified (votingCategory attribute of parent element)

b) do not have verdict +1 (value attribute of parent element)

c) have not been casted by a user which is part of the CI_ROLE (see paragraph above)

have been filtered out.

After that, our VoteCounting filter will only match if at least two (minCount attribute) votes are left. If this is not the case, the surrounding VotingCondition will not be satisfied and as a consequence, its surrounding SubmitRule will not be satisfied either.

Introducing SubmitRule filters

powerexample step5 You shall not pass – Control your code quality gates with a wizard – Part III

So far, we only talked about voting conditions and its child filter elements. Sometimes, you do not want an entire submit rule to be evaluated if a certain condition is not fulfilled. Our second blog post already used a submit rule filter for a rule that should only be evaluated if a commit was targeted for the experimental branch.

Step 5  of our power policy is another example:  “Only team leads (a list of Gerrit users) can submit”

We will add a filter to our first submit rule that will make sure that it only gets evaluated if a team lead looks at the Gerrit change. As we only have three submit rules so far and the first one is the only one which can potentially be evaluated to allow, it is sufficient to add this filter only to the first one. To do that, we switch back to the Submit Rules tab, double click on the first submit rule and click on the Next button in the dialog that opens. After that, you can see four tabs, grouping all available submit rule filters. You probably remember those tabs from the second blog post where the values for those filters have been automatically populated based on the characteristics of an existing Gerrit change (more precisely, its latest change set).

This time, we will manually enter the filter values we need. Let’s switch to the User tab and select the accounts of your team leads. In the screenshot below you can see that we chose the accounts of eszymanski and dsheta as team leads.

 You shall not pass – Control your code quality gates with a wizard – Part III

Once you select your team leads instead (our wizard makes it possible to interactively select any TeamForge user or internal Gerrit account), let’s click on Back and finally adjust the display name of our submit rule to its new meaning: Code-Review+2-Verified-From-2-CI-And-Project-Lead-To-Submit

If we finish the dialog and switch back to the Source tab, you can see that our first submit rule has not only changed its displayName but also got a new child element:

 You shall not pass – Control your code quality gates with a wizard – Part III

The UserFilter element makes sure that the surrounding submit rule will only be evaluated if at least one of its CurrentUser child elements matches the user currently looking at the Gerrit change.

If there are multiple submit rule filters, all of them have to match if their surrounding submit rule should be evaluated. You may ask what happens if no submit rule can be evaluated because none of them has matching filters. In that case, submit will be blocked and a corresponding message displayed in Gerrit’s Web UI. The same will happen if you have not defined any submit rule at all. As always, you can test your submit rules directly in the wizard against existing changes before deploying.

Providing guidance to your users with display only rules

powerexample step5 You shall not pass – Control your code quality gates with a wizard – Part III

Before we design a submit rule for the final step (6), let’s try to remember the submit rule evaluation algorithm and what will happen if a non team lead looks at a Gerrit change with our current policy. Quoting from blog post two:

 You shall not pass – Control your code quality gates with a wizard – Part III

a) For every submit rule that can be evaluated, figure out whether its voting conditions are satisfied (if a submit rule does not have a voting condition, it is automatically satisfied)

b) If all voting conditions are satisfied for a submit rule, the rule gets evaluated to the action specified in the actionIfSatisfiedField (ignore if no value set), otherwise the rule gets evaluated to the action specified in actionIfNotSatisfied field

c) If any of the evaluated submit rules got evaluated to block, submit will be disabled and the display name of all blocking rules displayed in Gerrit’s UI as reason for this decision

d) If no evaluated submit rule got evaluated to block but at least one to allow, submit will be enabled

e) If all evaluated rules got evaluated to ignore, submit will be disabled and the display names of all potential submit rule candidates displayed

As our first submit rule (Code-Review+2-Verified-From-2-CI-And-Project-Lead-To-Submit) has a submit rule filter which will not match if you are not a team lead, this rule will not be evaluated. This leaves us with submit rules two (Code-Review-Veto-Blocks-Submit) and three (Verified-Veto-Blocks-Submit). Neither of those submit rules have a submit rule filter so they will always be evaluated. Both rules have one Voting Condition, checking whether there is any Code-Review -2 or Verified -1 vote. If the corresponding voting condition can be satisfied, the surrounding submit rule will be evaluated to block, blocking submit and showing its display name as reason within Gerrit’s Web UI.

Let’s pretend nobody has vetoed our Gerrit change so far. In that case, all evaluated rules will be evaluated to ignore and the final step (e) of our algorithm will kick in. Submit will be disabled and the display names of all potential submit rule candidates, IOW all evaluated submit rules which can potentially be evaluated to allow will be shown. In our case, there are no potential submit rule candidates though as the only submit rule which can potentially evaluate to allow is submit rule one. This submit rule was not evaluated though as its submit rule filter did not match (no team lead was looking at the change). As a result, Gerrit can only show a very generic message why submit is not possible, leaving non team leads confused on what to wait for.

How to give guidance under those circumstances? Should we just modify our algorithm and also display the display names of submit rules that did not get evaluated? Probably not. Imagine you have a secret quality gate for a group called Apophenia who can bypass other quality gates if the commit to the enigma branch if the number of lines added to the commit is 23 (for anybody who does not know what I am talking about, I can really recommend this movie).

The corresponding submit rule would have submit rule filters making sure that the rule only gets evaluated for that particular branch, commit stats and user group. As long as those filters are not matched, the display name of surrounding submit rule must not be revealed under any circumstances. We are sure you can imagine a more business like scenario with similar characteristics.

Fortunately, there is a way how to guide users under those circumstances: Display only rules

Display only rules are submit rules without any voting conditions and no submit rule filters. Consequently, they are always evaluated and will always satisfy. They do not have any value (or ignore for that matter) set for their actionIfSatisfied attribute though. Hence, they will never influence whether submit is enabled or not (that’s why they are called display only after all). Their actionIfNotSatisfied attribute is set to allow. This makes them potential submit rule candidates.  In other words, their display names will always be shown whenever no other submit rules allows or blocks submit, providing perfect guidance.

In our particular example, we will create a display only rule with display name Team-Lead-To-Submit which will give all non team leads guidance why they cannot submit although nobody vetoed the change.

At this point, we like to demonstrate another cool feature of the Source tab. It is bidirectional, so you can also modify the XML and your changes will be reflected in the first and second tab of our wizard. Let’s paste our display only rule as one child element of the GerritWorkflow element:

<cn:SubmitRule actionIfNotSatisfied="allow" displayName="Team-Lead-To-Submit"/>

If you switch back to the Submit Rule tab, it should look like this

 You shall not pass – Control your code quality gates with a wizard – Part III

You probably recognized that this is the first time we used the Not Satisfied Action field, admittedly for a quite exotic use case, namely display only rules. The final step in our power policy will hopefully demonstrate a more common use case to use this field.

Not Satisfied Action for Exception Driven Rules

powerexample step61 You shall not pass – Control your code quality gates with a wizard – Part III

Step 6 of our power policy is an example of what we call exception driven rule:

“If a file called COPYRIGHT is changed within a commit, a Gerrit group called Legal has to approve (Code-Review +2) the Gerrit change”

Why exception driven? Well, having somebody from Legal approving a change is not sufficient by itself to enable submit, so having a separate submit rule with actionIfSatisfied set to allow is not the answer. Should we then just add legal approval as voting condition to all submit rules which can potentially enable submit? This is probably not a good idea either. Not every commit has to be approved by legal, only the ones changing the COPYRIGHT file.

Hence the best idea is to keep the existing submit rules unmodified and add a new submit rule which will

I) if evaluated, checks whether legal has approved the change and if not blocks submit (exception driven)

II) only be evaluated if legal has to actually approve the change (if the COPYRIGHT file changed)

Let’s tackle I) first by creating a new submit rule (push Adding Rule Manually button) with display name Legal-To-Approve-Changes-In-Copyright-File and setting Not Satisfied Action to block.

 You shall not pass – Control your code quality gates with a wizard – Part III

If we kept our new submit rule like this, it would not block a single change as it does not have any voting condition (and hence would always evaluate to satisfied). So let’s add a voting condition that requires a Gerrit group called Legal to give Code-Review +2. The screenshot below shows how this condition should look like. In our case, Legal is a TeamForge user group (group1008).

 You shall not pass – Control your code quality gates with a wizard – Part III

In the current state, all changes which do not satisfy our new voting condition would be blocked.

Implementing II) will make sure we only evaluate this submit rule (and its voting condition) if the corresponding commit changed the COPYRIGHT file. To do that, we have to click on Next, and switch to the Commit Detail tab which contains all submit rule filters which match characteristics of the commit associated with the evaluated change. The only field to fill in is the Commit delta file pattern. Its value has to be set to ^COPYRIGHT as shown in the screenshot below.

 You shall not pass – Control your code quality gates with a wizard – Part III

Why ^COPYRIGHT and not just COPYRIGHT? If a filter name does not end with Pattern, it only matches exact values. If a filter ends with Pattern though, it depends on the field value.

If the field value starts with ^, the field value is treated as a regular expression. ^COPYRIGHT will match any file change list that contains COPYRIGHT somewhere. If the field value does not start with ^, it is treated as an exact value. If we entered just COPYRIGHT, this would have only matched commits where only the COPYRIGHT (and no other file) got changed. Keep this logic in mind whenever you deal with pattern filters. Branch filters and commit message filters are other prominent examples where using a regular expression is probably better than an exact value.

If we finish the dialogs and switch to the Source tab, you can see the XML for our new submit rule:

 You shall not pass – Control your code quality gates with a wizard – Part III

The actionIfNotSatisfied attribute is set to block, we have one submit rule filter (CommitDetailFilter) and one voting condition with a filter (VoteVoterFilter).

Congratulations, you have successfully designed the power policy and can now test and deploy it!

powerexample1 You shall not pass – Control your code quality gates with a wizard – Part III

Power example with six quality gates

Learning more about the XML based quality gate language

Although you have seen quite a bit of our XML based language so far, we fully realize that we have not shown you every single feature. We do not believe this is necessary though, as our graphical wizard supports all features of the language. If you are unsure how a certain filter works, just create one example with the wizard, switch to the Source tab and find out how to do it properly. Our schema is another great resource as it is fully documented and will make sure that you do not come up with any invalid XML document. Last but not least, our wizard ships with many predefined templates. We tried to cover every single feature of the language within those templates.

For those of you who are familiar with Gerrit’s Prolog cookbook, we turned all Prolog examples into our declarative language and were able to cover the entire functionality demonstrated. The results can be found here.

As always, if you have any questions regarding the language, feel also free to drop a comment on this blog.

How to deploy quality gates without the graphical wizard

As explained before, our Quality Gate enforcing plugin ties into Gerrit’s Prolog based mechanism to customize its submit behavior. Gerrit expects the current submit rules in a Prolog file called rules.pl in a special ref called refs/meta/config. The deployment process for rules.pl is explained here.

Whenever our wizard generates a rules.pl file, it makes use of a custom Prolog predicate called cn:workflow/2 which is provided by our Quality Gate enforcing plugin. This predicate has two arguments. The first one takes the XML content as is, the second one will be bound to the body of Gerrit’s submit_rule/1 predicate. In a nutshell, the generated rules.pl looks like this:

submit_rule(Z):-cn:workflow(‘<XML document describing your quality gate policy>’, Z).

Our wizard does not use any other Prolog predicates. You can use our predicate as part of your own Prolog programs if you decide to come up with your own tooling and generate rules.pl by yourself. While passing the XML content, make sure it does not contain any character which would break Prolog quoting (no ‘ characters no newlines or XML encode then). Our graphical wizard takes care of this step.

Final words and Call for Participation

If you made it through the entire third blog post you can proudly call yourself a wizard too icon cool You shall not pass – Control your code quality gates with a wizard – Part III

Designing quality gates from scratch can be a complex matter. Fortunately, our wizard comes with many predefined templates you can just deploy. In addition, we turned any example from the Prolog cookbook into our format. If you are unsure how to match a certain state of a Gerrit change, just use the built in functionality of our wizard to turn it into a submit rule and adopt it according to your needs. Before you deploy, you can always simulate your quality gates within the wizard. It will follow the submit rule evaluation algorithm step by step and shows the evaluation result for every rule. If you do not like our wizard and do not like Prolog either, feel free to use our XML based language independently. This blog post has demonstrated how to do that.

Talking about the XML based language, its specification is Open Source. We encourage you to build your own wizard or other frontends and will happily assist if you have any questions regarding its functionality. Gerrit’s functionality to customize submit behavior is unmatched in the industry. We hope that with our contributions we made it a little easier to tap into it.

Coming up with the wizard, the language and our backend was a team effort. About half a dozen people worked for two months to get to the current state. We like to know from you whether it is worth investing further in this area. Want to have more examples? Better documentation? A tutorial video? A Web UI based wizard? Performance is not right? Cannot express the rules you like to express? Want to use the feature with vanilla Gerrit?

Please, spread the word about this new feature and give us feedback!

The post You shall not pass – Control your code quality gates with a wizard – Part III appeared first on blogs.collab.net.

Categories: Companies

R: Rook – Hello world example – ‘Cannot find a suitable app in file’

Mark Needham - Fri, 08/22/2014 - 13:05

I’ve been playing around with the Rook library and struggled a bit getting a basic Hello World application up and running so I thought I should document it for future me.

I wanted to spin up a web server using Rook and serve a page with the text ‘Hello World’. I started with the following code:

library(Rook)
s <- Rhttpd$new()
 
s$add(name='MyApp',app='helloworld.R')
s$start()
s$browse("MyApp")

where helloWorld.R contained the following code:

function(env){ 
  list(
    status=200,
    headers = list(
      'Content-Type' = 'text/html'
    ),
    body = paste('<h1>Hello World!</h1>')
  )
}

Unfortunately that failed on the ‘s$add’ line with the following error message:

> s$add(name='MyApp',app='helloworld.R')
Error in .Object$initialize(...) : 
  Cannot find a suitable app in file helloworld.R

I hadn’t realised that you actually need to assign that function to a variable ‘app’ in order for it to be picked up:

app <- function(env){ 
  list(
    status=200,
    headers = list(
      'Content-Type' = 'text/html'
    ),
    body = paste('<h1>Hello World!</h1>')
  )
}

Once I fixed that everything seemed to work as expected:s

> s
Server started on 127.0.0.1:27120
[1] MyApp http://127.0.0.1:27120/custom/MyApp
 
Call browse() with an index number or name to run an application.
Categories: Blogs

Die Frage nach dem Warum

Scrum 4 You - Fri, 08/22/2014 - 07:30

Als ScrumMaster bzw. Agile Consultant stelle ich am Anfang von jedem Scrum Meeting immer dieselbe offene Frage in die Runde der Teilnehmer: „Weshalb ist dieses Meeting Teil des Scrum Flows?“ Wohlgemerkt: Das frage ich nicht nur, wenn ich ein Team gerade neu übernommen habe, oder wenn wir einen Termin neu gestalten. Für mich hat diese Frage einen positiven Aspekt, den man immer wieder wiederholen darf – jenen des kontinuierlichen Lernens und der Frage nach dem Sinn.

Eines habe ich nämlich durch Scrum gelernt: Es hat alles einen Sinn. Und wenn etwas tatsächlich doch keinen Sinn hat, dann ist es Waste und sollte tunlichst geändert bzw. abgeschafft werden! Da wir als Firma Boris Gloger Consulting immer öfter von Managern angerufen werden, um Scrum in ihren Unternehmen zu implementieren, hat der Begriff „Scrum“ bei vielen Mitarbeitern auch das Synonym „neuester Trend“. Gerade dienstältere Mitarbeiter belächeln mich dann manchmal und meinen nur „Sie wissen ja gar nicht, wie viele Prozesse wir hier schon kommen und gehen gesehen haben. Dieses Scrum wird der nächste gewesen sein“. Dagegen weigere ich mich jedoch. Ja, es ist aktuell trendy, agil zu arbeiten (siehe „Studie Agile Status Quo“). Doch gibt es auch einen guten Grund dafür!

Damit Scrum nicht nur als Trend wahrgenommen und gelebt wird, ist es wichtig, dass jene Menschen, die
damit arbeiten sollen, den Sinn dahinter erkennen. Und aus diesem Grund stelle ich die Frage nach dem „Warum“ am Anfang jedes (Scrum-)Meetings. Auch vor kurzem wieder am Anfang der Sprinthe-question-mark-350169_640t Retrospektive bei einem cross-funktionalen Team, das schon seit einem Jahr Scrum in der Hardware macht. Kleiner Tipp am Rande: Hört gut zu. Die erste Antwort beantwortet meistens das Was. Auch dieses Mal kam wieder die Antwort: „Wir schauen uns an, was im letzten Sprint gut gelaufen ist und was wir im nächsten Sprint anders machen wollen“. Ja – das ist korrekt. Doch beantwortet das meine Frage nach dem Warum? Nein. Also noch einmal fragen: „Weshalb sitzen wir jetzt in diesem Meeting?“

Ein schöner Nebeneffekt dieser offenen Frage ist, dass es Zynismus und lustige Kommentare zulässt. So kann man gleich mit einem Lachen in ein Meeting starten. Oder Bedenken aus dem Weg räumen. Falsche Interpretationen gerade ziehen. Einen Einblick in die Stimmung im Team bekommen. Und auch als Agile Consultant immer wieder Neues erfahren.

Versucht es selbst! Ich freue mich über Erfahrungsberichte.

Related posts:

  1. Die Retrospektive macht das Team, das Team macht die Retrospektive
  2. Scrum – wider die Methodenfixierung
  3. Klassiker | Sprint Planning

Categories: Blogs

The Agile Reader – Weekend Edition: 08/22/2014

Scrumology.com - Kane Mar - Fri, 08/22/2014 - 05:43

You can get the Weekend Edition delivered directly to you via email by signing up here.

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • What’s going on? Agile and Scrum Certification Online Free Webinar On How are Agile… http://t.co/kZzOXtsgdn
  • RT @magenic: How do you define success in an #agile environment? #scrum
  • “@bfavellato: Tutorials, Practices & Demos: IBM Rational Solution for #Agile ALM with Scrum @JazzDotNet @JazzHub”
  • RT @pisarose: Great ideas! A scrum approach to #content creation – @shellykramer #marketing #agile
  • 8 Ways to Avoid Making an #Agile Mistake #agiledevelopment #scrum
  • Interesting reading for the next week #agile #scrum #gamedev
  • RT @apuntoprieto: Interesting reading for the next week #agile #scrum #gamedev
  • <a href="
    Warning: require_once(/home3/clinton3/public_html/wp-settings.php): failed to open stream: No such file or directory in /home3/clinton3/public_html/wp-config.php on line 30
    http://clintonkeith.com/agd.html&nbsp”>RT : Interesting reading for the next week #agile #scrum #gamedev
  • Keep it Simple: What is Agile SCRUM: #scrum #agile
  • How to help a team that is not performing so well – Part I – #scrum #agile #learning #improvement
  • RT @AgileBelgium: #Agile Tour Brussels 2014: program published, registration open. #atbru #program #published #scrum…
  • RT @yochum: Scrum Expert: Patterns: a New Standard for Scrum #agile #scrum
  • Read this #Kindle #8399

    The Scrum Checklist, For the Agile Scrum Master, Product Owner,… http://t.co/yUjUOdOomR

  • Read this #Kindle #8399

    How to Become a Scrum Master in 7 Simple Steps (Agile Project M… http://t.co/oao1BBUY4w

  • Read this #Kindle #8399

    Scrum, (Mega Pack), For the Agile Scrum Master, Product Owner, … http://t.co/Fu8olhfO5O

  • Interested in this job? Eliassen Group Agile Coaching & Senior Scrum Master Training in Bethesda, MD #agilecoach
  • Agile Transformation Program Manager – Scrum Master – 8188 #job
  • Agile Scrum isn’t a silver bullet solution for s/w development, but it can be a big help. #AppsTrans #HP
  • Using personas to drive epic & user story development: by @romanpichler #prodmgmt #agile #scrum
  • RT @lgoncalves1979: How to help a team that is not performing so well – Part I – #scrum #agile #learning #improvement
  • Are you thinking about getting a Scrum Master Certification? #agile #scrum
  • Here is my half day w/shop presentation on Leading Agile Virtual Teams, delivered at #LEADit #scrum #virtualteams
  • “Scrum is a means of becoming agile…but you can, and should outgrow it if you do it right.” @geoffcwatts #scrumish
  • Here is our half day w/shop presentation on Leading Agile Virtual Teams, delivered at #LEADit #scrum #virtualteams
  • CHECK THIS #BOOK #71084 #Kindle

    The Scrum Checklist, For the Agile Scrum Master, Produc… http://t.co/sHx8Y1K7Y2

  • CHECK THIS #BOOK #71084 #Kindle

    How to Become a Scrum Master in 7 Simple Steps (Agile P… http://t.co/lhocB5NJ2e

  • CHECK THIS #BOOK #71084 #Kindle

    Scrum, (Mega Pack), For the Agile Scrum Master, Product… http://t.co/iGZxmFryVa

  • Check this out: The FREE SCRUM EBOOK as sold on Amazon. #Scrum #Agile inspired by #Ken Schwaber
  • RT @AgileBelgium: #Agile Tour Brussels 2014: program published, registration open. #atbru #program #published #scrum…
  • Software – Introduction to scrum training and agile training at #approach #scrum #tortillis #organizations
  • RT @ScrumDan: Everyone has been asking me to sell my user Story Cards. #agile #scrum
  • Agile Scrum isn’t a silver bullet solution for s/w development, but it can be a big help. #AppsTrans #HP
  • Read Book : #Kindle #5142 #9: Succeeding with Agile: Software Development Using Scrum

    S… http://t.co/Tz3pnSodf5

  • Read Book : #Kindle #5142 #1: Scrum Shortcuts without Cutting Corners: Agile Tactics, To… http://t.co/exXFblQpVS
  • RT @rhundhausen: One blog to inform them all: High quality #Scrum and #Agile posts by high quality practitioners #pr…
  • Here’s how we built the New – Iterative Agile Development Lessons #scrum #agile #iterative
  • RT @BDCEng: Here’s how we built the New – Iterative Agile Development Lessons #scrum #agile #…
  • Read Now #7153 #Kindle

    The Scrum Checklist, For the Agile Scrum Master, Product Owner, … http://t.co/2u5OQmFWVo

  • Read Now #7153 #Kindle

    How to Become a Scrum Master in 7 Simple Steps (Agile Project Ma… http://t.co/k707gBuGhN

  • Read Now #7153 #Kindle

    Scrum, (Mega Pack), For the Agile Scrum Master, Product Owner, S… http://t.co/UXjx7ILtrh

  • #Kindle #3: Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addis… http://t.co/pHtlthstma
  • Books & Deals >> #32033 #Kindle

    Scrum Shortcuts without Cutting Corners: Agile Tactics,… http://t.co/fvfDxQmkBw

  • Paperback Scrum: Need a scrum guide: #scrum #agile
  • Lean, Agile & Scrum Conference – Dave Snowden @beyondreqs #cynefin… http://t.co/qPvMd3KRau
  • RT @techXOcafe: Lean, Agile & Scrum Conference – Dave Snowden @beyondreqs #cynefin… http://t.co/qPvMd3KRau
  • RT @gabrielagill53: Making employees happy = #successful company!! @Happy_Melly #scrum #agile #awesome @WIKISPEED
  • Pega Application Developer to join our #EmployeroftheWeek #securityclearance #Agile #Scrum
  • Pega Application Developer to join our #EmployeroftheWeek #securityclearance #Agile #Scrum
  • Pega Application Developer to join our #EmployeroftheWeek #securityclearance #Agile #Scrum
  • RT @yochum: Scrum Expert: Patterns: a New Standard for Scrum #agile #scrum
  • RT @ScrumDan: Everyone has been asking me to sell my user Story Cards. #agile #scrum
  • Agile by McKnight, Scrum by Day is out! Stories via @StratacticalCo @trompouet
  • RT @ClearedJobsDC: Pega Application Developer to join our #EmployeroftheWeek #securityclearance #Agile #Scrum
  • CHECK THIS #BOOK #71084 #Kindle

    Scrum Shortcuts without Cutting Corners: Agile Tactics,… http://t.co/mzo4x9rVBj

  • RT @rhundhausen: One blog to inform them all: High quality #Scrum and #Agile posts by high quality practitioners #pr…
  • The Best Books : #9516 #Kindle

    Scrum Shortcuts without Cutting Corners: Agile Tactics, … http://t.co/OGeJkB0zkU

  • What does the Scrum Master actually do in agile projects? – http://t.co/LvrgDthKV7
  • [QUESTION] The Product Owner Says #NoEstimates From the Team. Now what? #Agile #Scrum #PM #pmot
  • Categories: Blogs

    Does the actual experience at your organisation reflect a supporting culture?

    One of my favourite books that I've read recently is True Professionalism by David H. Maister. In it, he references another of his books, Managing The Professional Service Firm, about asking junior professionals about their experience on work assignments.

    I think this list of questions is generally applicable even outside of professional service firms to assess whether the body language of an organisation actually indicates a supporting culture, independent of what might be claimed:

    Is it usually true that...
    1. When work is assigned, you understand thoroughly what is expected of you
    2. You understand how your tasks fit into the overall objectives of the project, engagement, organisation
    3. You are kept informed about the things that you need to know in order to do your job properly
    4. You receive good coaching to help improve performance
    5. You receive prompt feedback on your work, good or bad
    6. You feel that you are a member of a well-functioning team
    If you flip this around, we can use this as a checklist for when you take on work:
    1. What is expected of me for this work?
    2. How do my tasks fit into overall objectives?
    3. Do I need to know anything else in order to do this job properly?
    4. Who will support me to help improve my performance?
    5. How will I get feedback on whether the work is good or bad?
    6. Who will be part of my team and how will we interact?
    Categories: Blogs

    New Sprintly Feature: Change Item Type

    sprint.ly - scrum software - Thu, 08/21/2014 - 20:49

    One of our top requested Sprintly features is “how do I change the item type?” Ever file a defect in Sprintly and realize that it should have been a task? Today we’ve shipped this ever useful feature!

    Place an item in edit mode via the gear icon, select the new item type and hit Update. In this example, I changed a defect into a task:

    image

    You won’t be able to change a Story into another item type at this point. Stories are unique in that they can have sub-items. Tasks, defects and tests cannot have sub-items.

    We hope you enjoy this Sprintly product update and always, let us know how we can be of help.

    Categories: Companies

    Open a Github Issue From Slack!

    The other day one of my co-workers opined that it’d be fantastic if we could open a GitHub issue from Slack. Fifteen minutes later the channel got to bask in the awesomeness… of this!

    Read on to discover how to use Zapier (shameless plug: yes, I work on this) to whip this up quickly as well!

    Opening the Issue

    First up, we need to log in to Zapier and set up our first of two Zaps, the one that will create a new issue from Slack.

    Now we’ll select our two services and the desired actions:

    Next up, connect Slack and GitHub to Zapier.

    When we get to step four, we’ll want to setup a custom filter so that we only trigger on Slack messages that contain !gh_issue.

    At step five we’ll want to plug the values in to the GitHub issue from Slack. If you scroll back you’ll remember we used a specific format for our issue:

    !gh_issue title(Junk Issue) description(Junk Issue!) repo(zapier/zapier-infra)

    In Zapier-land, we extract those elements with parenthesis as variables. So when pulling from the trigger we get the raw text and the extracted variables as names like {{text__title}}, {{text__description}}, etc.

    At step six we’ll load some samples.

    Hrmph. All filtered out. Ah! We haven’t actually tried to create an issue from Slack. Let’s go do that now!

    Now we go back to step six and refresh and we should see a new unfiltered sample, of which we can click “See filter sample” to view what will go to GitHub.

    Looks good! Let’s go ahead and click “Test” and check that the GitHub issue was created on GitHub.

    Great! Let’s go ahead and name this Zap!

    But that’s only half the story. It’d also be nice if there was some notification in the channel that it had been created. Not 100% needed, but it would be nice!

    The Webhook

    So we have multiple ways we could approach this here:

    • Create a Zap that polls GitHub issues and alerts the channel of new issues
    • Setup a webhook through Zapier to push new issues instantly to Slack
    • Use the native Slack/GitHub integration on Slack to send the new issue notification

    I’ll admit I didn’t have much luck using the native integration despite wanting it to work as it would have required the least amount of setup. Polling was easy to setup, but it means I can have anywhere from a 1 minute to a 15 minute delay from when I open the issue to when it is published back to Slack. So I opted for the webhook route.

    The Webhook Trigger on Zapier is immensely powerful. You can use it to poll a URL, catch incoming webhooks, and even send webhooks back out to other services. It’s pretty raw but it gets the job done, and it gets it done instantly.

    Like last time, for step one we will select our services: Webhook to Slack!

    In step two, we’ll be given a webhook we can copy and paste to plug it into GitHub. Let’s navigate to GitHub really quick to add it.

    In our repository settings page on GitHub, let’s add a new webhook.

    By default this will fire on all events. We don’t want that, we want each issue.

    This will be grayed out until an event fires, so let’s go back to Zapier and continue working on our Zap.

    On step four, we’ll want add a custom filter so that the Zap will only trigger when issue action is equal to “open”. Otherwise this will fire whenever any activity takes place, such as opening and closing issues.

    The first time through you may get a modal pop up prompting you to go create a new issue when you try to select a field. This is because webhooks are instant and require a user interaction to take place first. So go create an issue (manually or from Slack, it doesn’t matter) and follow the instructions to get it caught by Zapier. Now we can select the field we need and move on. :-)

    At step five it’s time to set up the channel the message will be sent to and what the message will be. I typically prefer to alert the channel of a new issue opened on a repository and then link to it.

    There is also a field for Icon URL that can be used to plug in a specific icon for the Slack bot that broadcasts the message. I usually use a character of ours (Zapbot!) that is similar to Hubot, but Octocat fits well here too!

    Now we’ll test the Zap and if all goes well, name it and set it live!

    Whelp that wraps it up for us… hope you find these Zaps as useful as we have!

    Categories: Blogs

    Patterns: a New Standard for Scrum

    Scrum Expert - Thu, 08/21/2014 - 18:08
    Patterns are the new defacto Scrum standard. In recent years, international Scrum Leadership has been meeting about once a year to write a rationalized foundation for Scrum using Organizational Patterns as a public resource. This is the most inclusive forum for segments of the Scrum community meet and find common ground in the deep groundings of Scrum, and it is converging on a socially agreed definition while the certifying bodies have take less compelling paths. Jeff Sutherland’s Scrum training now revolves around the application of seven Scrum patterns. Using the same approach ...
    Categories: Communities

    Lean Agile Scotland, Edinburgh, Scotland, September 11-12 2014

    Scrum Expert - Thu, 08/21/2014 - 17:37
    Lean Agile Scotland is a two-day conference focused on the Lean and Agile approaches to software development. It will be preceded by a workshop on September 10. In the agenda you can find topics like “Join the Dark Side – why developers should choose management”, “Building the Boardwalk Empire: Visual Management in Action”, “Overcoming Self-organization Blocks”, “Lean Estimation & Planning”, “Better Decision Making: Gathering Data and Mapping Decisions”, “Lean Product is about the people – Putting it all together”. Web site: http://www.leanagilescotland.com/ Location for the 2014 conference: Our Dynamic Earth, Holyrood Rd 112, ...
    Categories: Communities

    Sample Page

    Manage Well - Tathagat Varma - Thu, 08/21/2014 - 17:11

    This is an example page. It’s different from a blog post because it will stay in one place and will show up in your site navigation (in most themes). Most people start with an About page that introduces them to potential site visitors. It might say something like this:

    Hi there! I’m a bike messenger by day, aspiring actor by night, and this is my blog. I live in Los Angeles, have a great dog named Jack, and I like piña coladas. (And gettin’ caught in the rain.)

    …or something like this:

    The XYZ Doohickey Company was founded in 1971, and has been providing quality doohickies to the public ever since. Located in Gotham City, XYZ employs over 2,000 people and does all kinds of awesome things for the Gotham community.

    As a new WordPress user, you should go to your dashboard to delete this page and create new pages for your content. Have fun!

    Categories: Blogs

    Hello world!

    Manage Well - Tathagat Varma - Thu, 08/21/2014 - 17:11

    Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

    Categories: Blogs

    News update 2014/08 – 5 Reasons to Kill Time Sheets

    ScrumSense.com - Peter Hundermark - Thu, 08/21/2014 - 14:58

    Welcome to our August newsletter. Do you also have a dislike for time tracking? Joanne Perold does, and she explains why in this month’s blog post….more.

    Kanban Foundation TrainingKanban Training

    We still have spaces available on our upcoming Kanban Foundation and Advanced courses. Scrum Sense will once again be teaming up with LKU-accredited Kanban Trainer, Dr. Klaus Leopold of LEANability to present this training.

    Kanban foundational course provides insight and visibility to the “why” of doing things – Dean Harvey, Nedbank Ltd.

    The Applying Kanban (Foundation) and Improving & Scaling Kanban (Advanced) certified courses will be taking place in Sandton on the 20-21 Oct and 23-24 Oct 2014 respectively. We are running a 3-for-2 special offer on both courses, so be sure to secure your place!

    Interesting Links
    • InfoQ has published the first in a series of articles from the short book “Leading Self-Organising Teams” written by Dr. Sigi Kaltenecker & Peter Hundermark. The first article is on “what are self-organising teams?” In the coming weeks this will be followed by “why do we need self-organising teams?” and “what is Leading Self-Organising Teams all about?”. Be sure to follow this series!
    • Dillon Weyer of Scrum Sense has written a blog post on the importance of a defined outcome. The title, “Without an outcome in mind, any road will do!“, perfectly sums up the significance of having an outcome.
    Upcoming Courses

    Certified Scrum Master (JHB) 
    02-03 Sept 2014
    FNB Conference & Learning Centre, Sandton

    Leading Self-Organising Teams (JHB)
    16-17 Sept 2014
    FNB Conference & Learning Centre, Sandton

    Certified Scrum Product Owner (JHB)
    30 Sept-01 Oct 2014
    FNB Conference & Learning Centre, Sandton

    Applying Kanban (Foundation) – (JHB)
    20-21 Oct 2014
    FNB Conference & Learning Centre, Sandton

    Course schedule and Book Online

    The post News update 2014/08 – 5 Reasons to Kill Time Sheets appeared first on ScrumSense.

    Categories: Blogs

    You shall not pass – Control your code quality gates with a wizard – Part II

    Danube - Thu, 08/21/2014 - 14:56
    You shall not pass – Control your code quality gates with a wizard – Part II

    In the previous blog post you learned how to select, test and deploy predefined quality gates with CollabNet’s code quality gate wizard for Gerrit. Those quality gates will make sure that all conditions regarding code quality and compliance are met before a commit can be merged into your master branch and trigger a pipeline that will eventually promote it into production.

    In this blog post we will focus on how you can define quality gates by yourself, using a methodology very close to setting up email filter rules.

    Underlying technical concepts of quality gates

    Before we jump into the functionality of the wizard, let’s give a short overview on the underlying foundations (I am sure most of the technical folks will appreciate). TeamForge is using Gerrit (current version 2.8, 2.9 coming soon) as its Git backend. If you are new to Gerrit, we recommend to have a look into this brilliant series of free, recorded webinars. The third and final part of his series is the best introduction into Gerrit’s change based workflow I have seen so far.

    If you prefer written explanations and pictures over webinars, I can recommend this blog post from my colleague Dharmesh.

    When we are talking about commits, we are referring to commits which are controlled by Gerrit’s review workflow, in other words, Gerrit changes. TeamForge comes with multiple review policies for Gerrit repositories which automatically make sure that Gerrit access rights are setup in a way that you cannot directly push to real branches but always have to go through the Gerrit review process (which does not mean you have to involve any manual reviewers or build systems, see below). When we are talking about pushing commits into production, we are referring to Gerrit’s functionality to submit/merge changes to their anticipated target branch which in turn trigger CI systems which will be responsible for all further actions. Quality gates are a collection of submit rules which define under which conditions Gerrit allows to submit a change. In a vanilla Gerrit, the only way to customize those conditions is to write Prolog programs. CollabNet’s Code Quality Gate Wizard for Gerrit shields its users from the complexity of Gerrit’s Prolog based system (more details in the third part of our blog post series).

    The following Prezi shows how our idea was presented at the latest Gerrit User Summit.

    You shall always pass – Simple example to start with

    submitalwaysenabled You shall not pass   Control your code quality gates with a wizard   Part II

    Enough with grey theory, haven’t we mentioned multiple times that setting up quality gates is as easy as setting up email filters? Let’s stick to our word. Inside the quality gate wizard, we have three tabs. The first one allows you to edit the title and description of your policy, testing it against Gerrit Changes (dry mode) as well as deploying it to Gerrit.

     You shall not pass   Control your code quality gates with a wizard   Part II

    The picture above shows the first tab of the wizard with a very simple policy: Submit is always enabled, in other words “You shall always pass”. This policy makes it possible to push any commit into production, more precisely, any Gerrit change will be submittable immediately. In addition to the title, description, test and deploy elements, you will notice two check boxes: Enable code review and Enable verification. Those checkboxes define whether users looking at a commit will be presented with the ability to give a Code-Review/Verified votes on the corresponding Gerrit change. This is independent of their actual permissions. In other words, if a user does not have permissions to cast a Code-Review or Verified vote, then this check box will not magically enable them to. As the Submit is always enabled policy allows to merge a commits unconditionally (i.e. as long as the user submitting the corresponding Gerrit change has Gerrit Submit permissions), there is no need to present users with Code-Review or Verify options, so those check boxes are not checked.

    The second tab of the quality gate wizard shows the actual submit rules. Submit rules are the technical details behind every policy you can define in the quality gate wizard. Like an email filter, submit rules have actions. While an email filter allows you to specify whether to delete or move an email into a subfolder, submit rule actions define whether to allow a commit to be merged into production, whether to block merging or not to do anything (ignore).

     You shall not pass   Control your code quality gates with a wizard   Part II

    The Submit is always enabled policy has only one submit rule whith action set to allow if it is satisfied. As there is no condition associated with this rule, it will always be satisfied, so it will always result in allow and hence will always enable Gerrit’s submit action.

    You shall never pass – Designing the opposite policy

    submitneverenabled1 You shall not pass   Control your code quality gates with a wizard   Part II

    Let’s have a look at the opposite policy – Submit is never enabled

     You shall not pass   Control your code quality gates with a wizard   Part II

    In contrast, the satisfied action is set to block. If a submit rule gets evaluated and results into block, Gerrit’s submit action is disabled, IOW the Gerrit change cannot be submitted, so the corresponding commit cannot be merged into its target branch and hence this code cannot be pushed into production.

    You shall pass as usual – Gerrit’s Default Submit Policy

    Too simple examples? Let’s move on then and examine Gerrit’s factory settings. CollabNet’s Quality Gate Wizard includes a template called Default Gerrit Submit Policy which simulates Gerrit’s standard submit behavior.

    gerritdefaultpolicy You shall not pass   Control your code quality gates with a wizard   Part II

    This policy consists of three submit rules:

    1. If somebody gave Code-Review +2 and there is also at least one Verified +1 vote, submit is allowed

    2. Any Code-Review -2 vote blocks submit

    3. Any Verified -1 vote blocks submit

    The screenshot below shows the conditions of the first rule in detail (you get to the voting condition dialog if you double click on a submit rule).

     You shall not pass   Control your code quality gates with a wizard   Part II

    The algorithm deciding who shall pass

    At this point, we have to elaborate a bit what happens if multiple rules are satisfied. First of all, the order of rules does not play any role, it can be completely ignored. The algorithm used to decide whether submit is enabled or not, looks as follows:

     You shall not pass   Control your code quality gates with a wizard   Part II

    a) For every submit rule that can be evaluated, figure out whether its voting conditions are satisfied (if a submit rule does not have a voting condition, it is automatically satisfied)

    b) If all voting conditions are satisfied for a submit rule, the rule gets evaluated to the action specified in the actionIfSatisfiedField (ignore if no value set), otherwise the rule gets evaluated to the action specified in actionIfNotSatisfied field

    c) If any of the evaluated submit rules got evaluated to block, submit will be disabled and the display name of all blocking rules displayed in Gerrit’s UI as reason for this decision

    d) If no evaluated submit rule got evaluated to block but at least one to allow, submit will be enabled

    e) If all evaluated rules got evaluated to ignore, submit will be disabled and the display names of all potential submit rule candidates displayed (details below)

    Potential candidates explained

    gerritdefaultpolicy You shall not pass   Control your code quality gates with a wizard   Part II

    Going back to Gerrit’s Default Submit Policy, this means that if rule two (Code-Review-Veto-Blocks-Submit) or three (Verified-Veto-Blocks-Submit) are satisfied, Gerrit will block submit and show their display names as reasons, no matter whether the voting conditions for rule one (Code-Review+2-And-Verified-To-Submit) are satisfied. Only if those two rules are evaluated to ignore (as their actionIfNotSatisfied field is implicitly set to ignore) and rule one is evaluated to allow, submit will be possible.

    So what happens if there is no Code-Review or Verifed-Veto but the change has not received both Code-Review +2 and Verified +1 votes yet? In that case we end up with the last step in our algorithm where you probably stumbled over the term potential submit rule candidates. Potential candidates are all submit rules that got evaluated and have at least one of their actionIfSatisfied and actionIfNotSatisfied fields set to allow. What does this mean exactly? Well, let’s think about a user who is looking at a Gerrit change in that very state.

    The screenshot below shows a change like that.

     You shall not pass   Control your code quality gates with a wizard   Part II

    There are no hard blockers (rule two and three) but as long as rule one is not satisfied, submit is still not enabled. How would the user looking at the Gerrit change even know what to do in order to enable submit? This is where potential candidates come into play. These are all rules which could potentially evaluate to allow, hence making the change submittable. Their display names are now shown in Gerrit’s UI as a hint for the user what possibilities exist to merge the corresponding commit and push it to production. In our case, that is the display name of rule one (Code-Review+2-And-Verified-To-Submit, see last line of screenshot above).

    Turning a Gerrit change into a submit rule changebaserule step4 You shall not pass   Control your code quality gates with a wizard   Part II

    Changed based quality gate

    So far, the examples provided did not add any particular value to what is already working out of the box in a standard Gerrit environment. Let’s switch gears and add a more interesting submit rule: If the target branch of a Gerrit change is called refs/heads/experimental, we will not need a Code-Review+2 anymore. Instead, having at least two Code-Review +1’s will be sufficient, or more precisely, the sum of all Code-Review Votes should be at least 2 in order to allow submit. Verified votes are not needed in this case but the blocking behavior of rules two and three will still apply. Like an email filter rule wizard, our quality gate wizard supports turning existing Gerrit changes into submit rules. We will use that very feature now to turn a Gerrit change for the experimental branch which has two Code-Review +1 votes into a submit rule.

    If you press on the button Add Change-Based Rule, a wizard similar to the one below appears. We will select the very Gerrit change we were looking at in the screenshot above as it already has the conditions we wanted to capture in a submit rule: Two Code-Review +1 votes, one Verified +1 vote and target branch experimental.

     You shall not pass   Control your code quality gates with a wizard   Part II

    We are only interested in copying the Voting details and Commit and change details. If you like to design a submit rule that copies Commit stats (like lines modified, deleted within the commit) or User and group details (who voted, who owns the change, which groups those users belong to), you have to check additional check boxes in the wizard. Once you click finish, a new dialog will open with the generated submit rule.

    The generated submit rule will match the Gerrit change it was based upon as close as possible. In practice, this is probably too narrow, as you like to match similar (same branch) but different (other files changed, different commit message) Gerrit changes too. Consequently, we now have to remove some voting conditions and filters. First though, we will change the display name of the new rule to Experimental-Branch-Adds-Up-Votes. Then, we will remove all but the last (Code-Review) voting condition as those are too narrow for our use case. Now, we double click on the last remaining voting conditions, clear out all filters and only keep the minSum=2 setting:

     You shall not pass   Control your code quality gates with a wizard   Part II

    like in the screenshot above. Once we click Next, we will see some further filters with values populated by our wizard based on the characteristics of our change. If any of those filters is not matched by a Gerrit change, the whole submit rule will not be evaluated, so we have to make sure to only keep the filters which are relevant for our use case. In our example, the only relevant filter is a change detail filter specified in the branch pattern field (see screenshot below). All other filters should be cleared as they are too narrow for our use case.

     You shall not pass   Control your code quality gates with a wizard   Part II

    Finally, click on Finish and deploy the new policy into your repository. The end result should look like this:

     You shall not pass   Control your code quality gates with a wizard   Part II

    You can use the testing facilities shown in the first blog post if you want to simulate the impact of the policy first. If we now look at the Gerrit change again, it will actually be submittable:

     You shall not pass   Control your code quality gates with a wizard   Part II

    Sharing your results

    Like your new policy and want to share it with your organization? Good! There are two ways of sharing your results: Saving them directly in the repository as an XML file and saving as an XML file on your hard disk. If you save them within a Git repository, the wizard will automatically create a commit and push it to a special Gerrit reference (refs/meta/config), so your ordinary code and branches inside that repository will not be affected. You may wonder what the difference is between deploying a policy to Gerrit and committing the XML file to refs/meta/config. The policy currently enforced by Gerrit is saved in a file called rules.pl and the Deploy button in our wizard makes sure this file name is used whenever you deploy. If you want to store a policy within the repository but do not want to enforce it there, just enter any other filename, the wizard will automatically append an .xml suffix to it.

    Whether you like to save an XML file to your local file system or save the file within the repository, it all starts with the File -> Save action for your editor (you can use CTRL+S shortcut or the floppy icon too).

     You shall not pass   Control your code quality gates with a wizard   Part II

    When opening the quality gate wizard, you can select to open an XML file from your file system, the currently enforced policy (rules.pl)  or any stored but not enforced policy inside the repository you are currently looking at.

    One idea how to centrally manage your quality gate policies is to create a dedicated Git repository where you can save all your policies. This is possible because you can load policies from different repositories of the same TeamForge project as where you deploy them. Please tell us if you see the need for an even more centralized solution.

    Summary

    In this blog post we demonstrated how you can design simple quality gate policies by yourself. A policy consists of one or more submit rules. When submit rules are evaluated, their voting conditions will be checked. Similar to an email filter rule, you can define actions based on the result of this evaluation, namely allow, block or ignore. You also learned about the algorithm used to determine whether a Gerrit change is submittable based on those actions. Basically, block actions will block submit no matter what, if no block is there, allow actions will make changes submittable and if there are only ignore actions, Gerrit will guide the users by displaying the names of all evaluated submit rules which could potentially still result in an allow action.

    If you have a Gerrit change with characteristics that should enable or disable commits to be pushed into production, you can turn them into a submit rule. The wizard will inspect the Gerrit change and setup the submit rule filters and voting conditions as precise as possible (similar to an email filter rule wizard you point to an existing email). You will have to clear the filters you are not interested in to make sure that your filter criteria are not too narrow for your use case. Only submit rules which match all filters specified will be evaluated by the algorithm that decides whether to allow or block the change from entering its target branch.

    While going through the change based submit rule wizard, you have probably wondered about all the possible filters and conditions you can specify. We encourage you to go through the list of all predefined quality gate policies and learn how those filters are used in detail. The next blog post will also show some further filters in action.

    Once you came up with your own policies, you can share them with your organization by either exporting them into an XML file or saving them in a dedicated Git repository.

    Coming up next …

    There is one tab in the quality gate wizard we have left out so far: The last tab is showing an XML representation of the language used to describe the policy you are currently looking at. In the third blog post we will exploit the full capabilities of that language, designing a real powerful policy, namely

    • Author Must Not Approve own changes (4 Eye Principle)

    • Legal has to approve changes in copyright file

    • Only verified from 2 CI users counts

    • Only team leads can submit

    powerexample You shall not pass   Control your code quality gates with a wizard   Part II

    Quality Gates enforced in part three of our blog post series

    The power policy is developed step by step, covering all details of our submit rule evaluation algorithm. Finally, we will also explain how to use this language independently from our graphical wizard for your own tooling. If you would like to become a quality gate wizard yourself, read on!

    The post You shall not pass – Control your code quality gates with a wizard – Part II appeared first on blogs.collab.net.

    Categories: Companies

    Knowledge Sharing


    SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.