<![CDATA[DevOps Transformation @Coresystems - Medium]]> https://medium.com/devops-transformation-coresystems?source=rss----158184c93ad8---4 https://cdn-images-1.medium.com/proxy/1*TGH72Nnw24QL3iV9IOm4VA.png DevOps Transformation @Coresystems - Medium https://medium.com/devops-transformation-coresystems?source=rss----158184c93ad8---4 Medium Sat, 14 Nov 2026 04:51:31 GMT <![CDATA[DevOps: The beginning of Continuous testing]]> https://medium.com/devops-transformation-coresystems/devops-the-beginning-of-continuous-testing-5b0b84596cb1?source=rss----158184c93ad8---4 https://medium.com/p/5b0b84596cb1 Fri, 24 Nov 2017 09:12:37 GMT 2017-11-24T09:12:36.970Z As a product company in order to be successful on a competitive market you have to constantly adapt to new requirements, and therefore continually bring changes to your app. From a testing perspective this is really difficult to handle.

So as you might figure it out, manual testing is not a viable solution. It brings no value on the long term.

Continuous deployment and continuous delivery will lead to certain failure with manual testing.

So, Continuous Testing …

The Problem: Maintaining a Huge ecosystem, with a big monolithic backend and multiple clients that connect to it.

The first step into DevOps approach is creating an automated testing infrastructure that enables all teams to write quick and reliable tests.

For this we developed an in house Framework based on Selenium, Appium and a custom REST api client specific for Coresystems Cloud data manipulation.

We call it Coresystem.Brewery :D

This is a library that we import in every app project. It formed as a combination of all problems that we encountered over time and resolved, so that other test projects can benefit and use. As a result, all tests are similar, we can help each other and we can come up with brilliant solutions.

Also as part of the infrastructure tests are executed on our continues integration server (Bamboo) with Selenium Grid in combination with Appium server.

The final touch is given by Allure Reporting which is also integrated with Bamboo and gives quick feedback: an overview of the test coverage.

Also one of the backbones of automated test for DevOps are the Unit Tests.

Having a good code review process that will not allow code to be committed without unit test is really important. This will result in high unit test code coverage.

The Next steps in our plan is to integrate the sonar for our source code and start with performance test, automated creation of environments and continuous monitoring of out test environments.

Although we are in the first steps in implementing the DevOps methodology we are confident that this will improve quality and make the our solution more reliable.

DevOps: The beginning of Continuous testing was originally published in DevOps Transformation @Coresystems on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[How and why we started with moving to docker]]> https://medium.com/devops-transformation-coresystems/how-and-why-we-started-with-moving-to-docker-cb358768febe?source=rss----158184c93ad8---4 https://medium.com/p/cb358768febe Fri, 24 Nov 2017 09:10:55 GMT 2017-11-02T11:52:09.999Z Our company as many fast growing companies started to face several challenges. With growing number of developers, projects, teams and mainly various new application, complexity of our architecture grows significantly. Our current three tier infrastructure architecture (loadbalancer- app server- database ) have been serving us well. Uptime was high. Any component could fail without significant impact on our applications or whole solution. But …. (there is always some but…) with growing numbers of applications (and micro-services they are build on top of) it shows its weaknesses. In past we had one monolithic core with few services around, so we could have set of servers to run each service. Now(and in not so distant future) to have set of servers for each service would be more than luxury. So we started with multiple services as a processes in same set of servers (of course grouped by technology and so). This is not working quite well — partially because of influence which each service could have to others, partially because of work needed to add new service, partially because of deployments (we everything this automated via puppet and custom scripts, but is like inventing wheel again) and finally because new feature requests (like autoscaling, self healing, multiple versions of same service and others). All these things are pushing us towards significant change of our infrastructure. After some research we figured out that if we bundle our services into docker many issues we can address. If we use some orchestration framework to run our docker build containers — we will address all issues we have with current infrastructure.

After some research (with help of external guys skilled in docker world — thanks Adam :-) ) we decided to set our course to docker and kubernetes. We were warned that we will need to change things in our services to be able to run. Beside many others we need to get rid of sticky sessions, local logging and change ways of debugging.

I feel we are heading good direction as we were able to create development kubernetes cluster and port our first application there. We are able to build this first container in bamboo, push it to our private docker registry and deploy it on our development kubernetes cluster. In next weeks we will move forward with other services, more robust docker registry and other things necessary to address.

How and why we started with moving to docker was originally published in DevOps Transformation @Coresystems on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>