GitHub Actions: A first impression

I'm a regular user of GitHub. Recently I discovered GitHub also has a build-in CI/CD workflow solution called GitHub Actions. Curious about how this would work I decided to try it out. I had previously build a Jenkins Pipeline to perform several static and dynamic application security tests on a Java project and decided to try and rebuild this pipeline using GitHub Actions. This blog described my first experiences and impressions.

OWASP ZAP: A quick introduction

OWASP ZAP or Zed Attack Proxy is an open source dynamic application security testing (DAST) tool. It is available here and has a website with documentation here. I recently encountered it when looking for open source security test tools to embed in a CI/CD pipeline (here). I was surprised by how versatile this tool is. In this blog post I'll summarize several ways how you can use it. 

How to get most out of your PaaS solution

Many companies are starting to implement PaaS (platform as a service) solutions. There are obvious benefits such as easy patching, scaling, pay per use, etc. There are also challenges when implementing a PaaS solution. In this post I will describe some of the challenges and provide some suggestions to allow you to enjoy your PaaS solution to the fullest.

The post is based on my presentation of a customer case on the Oracle Cloud day the 6th of October in the Netherlands this year.

https://www.oracle.com/cloudday/index.html

This customer had implemented a private PaaS solution and had faced several challenges. In this post I would like to present some of my findings (mainly based on interviews) in order to help customers who are considering a PaaS solution to make a good start with their implementation. The challenges / benefits are valid for private PaaS and public PaaS solutions.

SOA Suite 12c: Best practices for project structure and deployment

Efficient usage of version control has specific requirements to allow identification of versions and synchronous development on different branches. Design time you will want to have your Service Bus projects in a single application in order to allow usage of shared objects. At deploy-time or when creating a release, you want to group SCA composites together with Service Bus projects. How do you combine these different requirements?

In this article I'll describe several practices and considerations which can help you structuring your version control and artifact repository. The main challenge is finding a workable balance between the amount/complexity your deployment scripts and developer productivity / focus on business value. A lot of scripts (large investment) can make it easy for developers on the short term, however those scripts can easily become a burden.

If you are just looking for some good practices to structure your version control and artifact repository, look at the list below. If however you want to know why I think certain things are good and bad practice, read on.

Continuous delivery culture. Why do we do the things we do the way we do them?

Usually at first there is a problem to be solved. A solution is conjured and implemented. After a while, the solution is re-used and re-used again. It changes depending on the person implementing it and his/hers background, ideas, motives, likes and dislikes. People start implementing the solution because other people do it or someone orders you to do it. The solution becomes part of a culture. This can happen to such extents that the solution causes increasing amounts of side effects, other new problems which require new solutions.

Some thoughts on Continuous Delivery

Continuous Delivery is something a lot of companies strife for. It is a software development practice which allows quick (continuous) delivery of software. Quick delivery means the software can quickly provide business value. Why is it difficult to achieve and what are the challenges which need to be faced? Inspired by a Continuous Delivery conference in the Netherlands and personal experiences, some personal thoughts on the subject. The bottom line is that it requires a cultural change in a company and it is a joint effort of several departments/disciplines to make it work. The below image is taken from here. The Continuous Delivery maturity model is an interesting read to understand what Continuous Delivery is and provides a way to measure where you are as a company.

Comparison of Jenkins and Hudson: Options for sharing configuration among projects

Continuous Delivery is a practice which follows from the principles behind the agile manifesto (http://agilemanifesto.org/principles.html); 'Our highest priority is to satisfy the customer through early and continuous delivery of valuable software'. Continuous Integration is a part of the process of Continuous Delivery in which source code changes are integrated and tested frequently in an automated way. Hudson and Jenkins are two products which can be used to implement Continuous Integration. These tools provide build job management, security, integration for products providing reporting capabilities, integration with version control and numerous plugins are available to provide additional functionality.

Hudson and Jenkins share a history. Sun Microsystems was the owner of Hudson. Oracle took over Sun Microsystems. Some friction ensued between the original developers of the product and Oracle. Since Oracle applied for the trademark in 2010 but was not the most contributing party, several developers decided to rename/fork Hudson and Jenkins was born. Since then the projects have diverged.

In this blog post I will look at how job configuration can be reused among projects in Jenkins and Hudson. Since the projects have diverged, the solutions provided will differ. Jenkins provides the Inheritance Plugin (https://wiki.jenkins-ci.org/display/JENKINS/inheritance-plugin) and the Template Project Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin). Hudson provides a core feature called Cascading Projects (http://www.eclipse.org/hudson/the-hudson-book/book-hudson.chunked/ch06.html#section-cascading-project).

Hudson Cascading Job configuration

The Jenkins Build and Delivery Pipeline plugins

Continuous Delivery (CD) is a design practice used in software development to automate and improve the process of software delivery (http://en.wikipedia.org/wiki/Continuous_delivery). Continuous delivery uses the notion of a deployment pipeline in order to validate code. At an abstract level, a deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users (http://www.informit.com/articles/article.aspx?p=1621865&seqNum=2). How can such a deployment pipeline be implemented?

In this blog post I'll describe the setup of my environment and my first experience with the Jenkins/Hudson Build and Delivery Pipeline plugins. What it can do to help implement a deployment pipeline and what it won't do for you.

(https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin)

(https://wiki.jenkins-ci.org/display/JENKINS/Delivery+Pipeline+Plugin)