There are different points of view on how logging levels should be used in code. I will share mine. My assumption is: «There should be no errors in logs when everything is fine.» The idea is that the strongest log level should trigger alarm causing immediate notification (push or SMS) to operations team. Accordingly, that’s how logging levels should be used: error – Some action should be taken immediately! Ops team should enable email or sms notifications when a message of that king appears in logs.

One of the challenge for start-up or any new project is to reduce amount of work yet to deliver full-featured product. Agile methodologies address this challenge on project management level. Let’s discuss one more approach to address it on architecture level: UI-first development. Delivering prototype to the client early is very important to project success. Client may have only general idea of a product he needs and prototyping may save a lot of time and efforts of the team by reducing amount of unnecessary work.

Recently I was asked how to start with testing UI before backend is completed. It depends on the product a lot. But when we’re talking about web, it is often not clear how the final solution should look like and behave. If so, it is not reasonable to spend much time writing UI tests using tools like Selenium before the first prototype is ready. It is not reasonable to write a presentation layer and, in some cases, a business logic on server side before it is clear what kind of data is required for UI.

You may find following tips useful when setting up continuous integration infrastructure. Security Use VPN or reverse proxy provider like to secure your CI infrastructure. Never make your real IPs publicly available, otherwise you increase a risk of being hacked. Jenkins Use master node and build agents. Master node acts only as web console. Nodes are for compiling and testing. Notifications If you’re using google apps for domain, you may use Google’s restricted SMTP server to send notifications.

Selenide is nice wrapper around selenium web driver allowing to simplify writting UI tests with Selenium.

Some of the cook features are:

  1. jquery-like selector syntax, e.g. $("div.myclass").is(Condition.visible)
  2. Automatic screenshots on assertion failure
  3. Easy starting Selenium WebDriver
  4. And others

So, let’s write some tests on selenide and make it run from maven in a normal browser or in headless mode.

I’m going to start a series of posts covering different aspects of DevOps.

Let’s start today with branching strategy called «dirty trunk». Actually, this is an attempt to avoid branching at all. The idea is that: