Part 1 looked at some of the basic principes of DevOps and Continuous Development as they relate to small projects.

The Starting Point

Currently I use:

• Java for development
• Gradle for build management (although not very well - this needs improvement)
• GitHub for issue tracking and central repo for open source projects
• BitBucket for issue tracking and central repo for closed source projects
• Spock for unit and integration testing
• Travis CI but really only to provide the "passing" badge ... Gradle does the work
• Coveralls as a way of presenting coverage stats on GitHub.
• FindBugs for static analysis
• Docker to create test environments
• Vaadin TestBench for functional testing of Vaadin apps - only useful if you use Vaadin of course
• Intellij IDEA Ultimate Edition as IDE

Test coverage is generally good, and static analysis fully managed (that is, raised issues are dealt with).

I have a release process which generates release notes and partly automates the process, but it is a bit flaky and needs rework. It is this which started me off on the DevOps journey.

Selecting the Tools

This list may grow .. or change ... as I progress, but there are so many tools to choose from I need to start somewhere.

Some are self-selecting because I already use them and am happy with them. Gradle, Spock and Vaadin TestBench fall into this category. (An earlier post describes my experiences of Spock)

One specific consideration is that whatever environments I need (including a build environment) should be definable as code - infrastructure & Ops are definitely my weak points, so would benefit massively from automation.

• Principle 5: Environments / infrastructure defined in code and version controlled.

Docker

At the moment Docker is the only serious candidate to meet Principle 5.

Composing

Docker compose and/or Terraform

CI / task orchestration

The obvious candidate is Jenkins although there are quite a few others, particularly if you include hosted services. I do not want to incur costs at this stage though, so I am restricting the choice to installable tools, and in particular those which have a Docker image.

I installed Jenkins(via Docker) and that worked Ok, but I did find Jenkins quite hard to set up and in danger of conflicting with what was set up in Gradle.

I will come back to this, but at the moment I am wondering whether a "proper" CI server is really necessary given the simple orchestration I need, and a distributed build probably unnecessary. (This assumes that Gradle is the primary tool (Principle 3 in previous post))

On the other hand, I really do not want to be re-inventing anything.

Repository Manager

Artifactory for artifacts through the build process
Bintray for released artifacts

Lifecycle tasks

Given Principle 3, each step in the diagram should have an associated Gradle task.

1. Trigger from Git - TBD
2. Unit Tests - Spock / JUnit
3. Integration Tests - Spock / JUnit
4. Sonar scan - Sonar plugin
5. Quality gate - coded in Gradle, using Jacoco report (experimental version looks good)
6. Sonar gate - deferred; there are some notes on the Sonar site
7. Create build info - bespoke
8. Changelog and Release Notes - GitPlus plugin - in progress
9. Push to Artifactory - Artifactory plugin
10. Pull from Artifactory - Artifactory plugin
11. Deploy to test - Docker plugin
12. Functional test - app specific. Vaadin TestBench for Vaadin apps
13. Pull from Artifactory - Artifactory plugin
14. Deploy to UAT - Docker plugin
15. UAT - manual. Needs something to flag completion / failure
16. Pull from Artifactory - Artifactory plugin
17. Tag release - GitPlus plugin
18. Merge to master - GitPlus plugin
19. Push master and tags to origin - GitPlus plugin
20. Push to Bintray - Bintray plugin
21. Deploy to Production - Docker plugin

Notes

The GitPlus plugin is currently being developed

DevOps is clearly the Big Thing of the moment in the development world. I don't intend to describe it here, there are many good articles to do that, but what I am going to do is chronicle my own voyage of discovery and my thoughts on how DevOps could or should apply to small projects.

I am hoping that will help me later to remember why I made the decisions I did (good or bad), and with luck will also help others on the same journey.

So if you develop smaller projects, particularly Open Source, I hope these posts may be of help to you. Your feedback, comments and suggestions would be very welcome.

Context

I now write software almost full time, and most of that is open source, but in the scheme of things these are small projects.

In my past I have been in development roles and management roles, and worked in small and large organisations, so I have a fairly broad perspective both technically and organisationally. At heart, though, I am a developer. The Ops part is the scary part!

Aim

Like most developers, I want to be achieve:

• A rapid release cycle for the benefit of end users, while developing and maintaining a reliable system
• The highest possible proportion of effort is applied to developing for end user benefit (which simply means automating as much as possible)

In my case, end users could be other developers (if I am producing an open source component) or real users (for cloud hosted solutions).

DevOps or Continuous Delivery?

There is so much overlap between DevOps and Continuous Delivery I wondered whether I was actually using the wrong terminology. This excellent blog helped me make up my mind. It is worth reading the whole blog, but this for me was the conclusive statement:

DevOps starts with manufacturing principles and a pragmatic understanding of human and team behaviour. Continuous delivery starts with academic and scientific principles.

On that basis, I am going with the DevOps label, simply because I recognise it as the kind of pragmatic approach I am familiar with. On the other hand, anything I can take from Continuous Delivery will be enthusiastically included!

Practical Principles

After saying I would use the DevOps label, I watched this Continuous Delivery video from the Gradle team. It is an excellent resource if you use Gradle, and useful even if you do not - the discussion of the pipeline is valuable on its own.

The video was incredibly useful in describing some principles based on vast amounts of practical experience.

Which branch?

The generally recommended Continuous Delivery approach seems to be to merge and deploy from the master branch, and then treat any failures in the 'master' build as highest priority. That is probably good for enterprise projects, but does not suit my circumstances well.

It makes the 'master' unstable - and I would rather that the master branch in my public repos are always stable. I will therefore only merge releases to the master branch.

* Principle 1: Use the develop branch for build, merge and test. Treat the 'master' branch as a release into production

As a side effect, that means the default branch for my public repos must be 'develop', so that Pull Requests are from 'develop'. I really must do that!

It also means that:

* Principle 2 Every commit (to 'develop') should be fit for release.

Standard CD practice, and fits well. The decision to release may be manual, but the idea is that the commit should be of sufficient quality to be released.

Overlapping tools

There is a massive overlap between, for example, Gradle and Jenkins (or any other CI server). Both have an enormous range of plugins, often achieving the same thing. That could easily get confusing, so one or other should take precedence.

I have elected to treat Gradle as the dominant player - I found Jenkins a bit confusing to use, but the main reason is that Gradle is naturally code driven (and therefore testable and under version control).

* Principle 3: Gradle is treated as the primary tool for the lifecycle pipeline, in the sense that the tasks are all defined in Gradle. The lifecycle process (the order of task execution) may become the province of the CI Server.

Of course, a fully-fledged CI Server will do a lot more than that, particularly for distributed builds, but we will see how this principle stands up.

Defining the Lifecycle

My first cut at defining the lifecycle is little different from the video above - there's no point in reinventing well tested wheels.

* Principle 4: A single lifecycle definition with optional steps is easier to understand and maintain

It seems probably that this can be achieved - for example, some small projects will not need integration testing, but it is better to have that as an optional step than a different lifecycle. Of course, a complex standard lifecycle with masses of optional steps would be a poor idea!

Next Steps

That is enough for one post ... the next will be looking at the plethora of tools available and trying to select just those which would serve my needs.

It is quite a while ago since I blogged about testing (or about anything else ...) but my last post on the subject concluded that AssertJ was the best option, for me at least.

I was using AssertJ with Mockito and the Mycila runner to support Guice. I was generally happy with that combination, although there were one or two odd syntactical problems in the transition from Java 7 to 8.

And then there was Spock.

First thoughts

I'm not even sure why I tried Spock in the first place - I didn't think there was anything especially wrong with the libraries I was using.

I also have to admit I am not a huge fan of Groovy in itself, although I am using Gradle (also written in Groovy of course) more and more. The power of Groovy, though, is when it is used to provide a well designed DSL.

Spock demonstrates this really well, so I gave it a try ... this post is a quick overview of my experience, based on several months of use. I am not trying to cover all of Spock's functionality here, but I can say that I have not found anything yet which the AssertJ/Mockito combination could do that Spock cannot do.

The "classic" approach

Using the AssertJ/Mockito approach, a trivial test might look like this

@Test
public void doTest() {

    //given
    objectUnderTest.prepare(5);
    when(mockCollaborator.getStatus()).thenReturn("x");

    //when    
    objectUnderTest.doSomething();

    //then
    assertThat(objectUnderTest.getState()).isEqualTo("OK");
    assertThat(objectUnderTest.isActive()).isTrue();
    verify(mockCollaborator, times(2)).getStatus();
}

The Spock approach

The equivalent in Spock would look like this:

def "prep value 5, Out returns OK and calls collaborator twice"(){
    given:
    objectUnderTest.prepare(5);

    when:
    objectUnderTest.doSomething();

    then:
    objectUnderTest.getState().equals('OK')
    objectUnderTest.isActive()
    2 * mockCollaborator.getStatus() >> 'x'
}

There are a few things to note:
* The name of the test, which also appears in the test results, is far more expressive
* The given / when / then causes are part of the DSL, not just comments, and will tell you if you have got it wrong
* The static imports have all gone
* The comparison methods in the 'then' clause are all 'native'
* The last line of the 'then' clause is an example of the one thing that may trip you up. It is saying that the mock is expecting to be called twice, and will return a value of 'x' on both occasions.

Spock processes mock interactions in a different way to Mockito, and that can cause some misunderstandings when migrating from one to the other. It is worth reading that part of the documentation thoroughly.

Not much difference?

At a quick look, apart from being neater, there does not seem to be a massive difference. In practice, though, I have found that neatness very productive ... even with code completion, 'assertThat .. isEqualTo' is a bit cumbersome, where using the native comparison methods is far more fluent.

The failure output from Spock is also an improvement on the classic approach, giving a better indication which part of a check has failed:

Condition not satisfied:

stack.size() == 2
|     |      |
|     1      false
[push me]

The only thing I miss are the collection methods of AssertJ - containsOnly(), containsExactly() - for example. But if I miss them too much, I can still use them in Spock.

Oh, and the Spock data driven tests are neat ...

Conclusions

Spock seems to be one of those tools which grows on you very quickly. At first, it seemed that its advantages were not that great, but after just a few days, the increase in fluency and productivity convinced me that the change would be worthwhile.

I don't generally convert existing tests unless they need modification, but conversion is not difficult either.

Now,it is all I use in Krail for new unit, and usually integration testing ... and on the rare occasion when I add a test method to existing JUnit tests, the "classic"method feels very clunky.

The learning curve for Spock is not steep - I just found that the way interactions are used take a little bit of getting used to, but the end result is extremely powerful.

If you are writing tests - I would strongly recommend that you give it a go. And if you are not writing tests ... well, it might be a very good idea to start :-)