kidwellj/findcommonground.uk
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Typos and small 'refactorings'.

Browse source
This commit is contained in:
Martin Danielsson 2016-06-07 16:43:09 +02:00
parent e054c205f7
commit fbe7457841
1 changed files with 7 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
_posts/2016-06-07-DevOpsDay-2016.md
View file

@ -14,15 +14,16 @@ What started as a little get together in one of our locations last year, grew a
{:.center}
![DevOps Day 2016]( /images/dev-ops-day-16/DSC_0179.jpg){:style="margin:auto"}
As special guest we had [Moritz Heiber](https://twitter.com/moritzheiber) from ThoughtWorks, talking about Continuous Delivery and immutable infrastructure. He talked how DevOps empowers teams, not just developers, to work together, leverage technology, to deliver software in a better, more effective way - and that's exactly what we are seeing within Haufe as well.
As special guest we had [Moritz Heiber](https://twitter.com/moritzheiber) from ThoughtWorks, talking about Continuous Delivery and immutable infrastructure. He also talked about how DevOps empowers teams, not just developers, to work together, leverage technology, to deliver software in a better, more effective way - and that's exactly what we are seeing within Haufe as well.
Small teams, getting the full responsibilty over the complete software delivery process, can change things massively. We had several talks from our projects where the build and deploy cycle came down from several people days to minutes, fully automated!
We are experimenting a lot with [Go.CD](https://www.go.cd/), an open source continous delivery tool by ThoughtWorks, but also using Jenkins and others still. The point for Haufe at this stage is not just the tooling though, it's the bringing it all together: Understanding what your software process is, including for example testing, made us realise how many different people, departments and processes are typically involved. Not always 100% in sync... Writing it all down, making it explicit, through config files, stored in a repository, is the foundation for improving things, to automate. Following the concept of immutable infrastructure, we pack all compontents into Docker containers and build from scratch, everytime. Which then makes us independent where to deploy to - locally on a dev machine, hosted or onto the cloud. So far we stayed away from using any cloud specific offerings, no Amazon EC2 or alike, but manage it all ourselves, using Docker machine, compose and swarm.
Automated testing was another topic for discussion - is there a need for manual testing? How can others deploy several times a day and still test everything? Again, testing, development, deployment all moves closer together and therefore automating your test processes across the board is a natural goal - start with unit tests, system tests, don't forget security, include API testing, end2end and UI. Include it in your pipelines, set up the test environments from scratch and pull the test cases out of a repository (immutable infrastructure!). Then just make sure you can all run it fast - and here comes the challenge for us again. Test automation is not new for us, we have automated test cases - a lot in some cases. But combine all of those you realize there is not enough time a night to run them all!
So apart from the different tools and frameworks you can use - we talked about SoapUI, Selenium, HP Lean FT and others - we have to think about when to test what. And maybe restrict ourselves more, leave some tests out, not run them all the time. Afterall, testing being part of the build and deploy cycle, which is being streamlined, we can always redeploy. Combined with the Microservices approach, you deploy small pieces - so there is only so much which can go wrong in one deployment.
We are experimenting a lot with [Go.CD](https://www.go.cd/), an open source continuous delivery tool by ThoughtWorks, but we are also still using Jenkins, and other tools. The point for Haufe at this stage is not just the tooling though, it's the bringing it all together: Understanding what your software process is, including for example testing, made us realise how many different people, departments and processes are typically involved. Not always 100% in sync... Writing it all down, making it explicit, through config files, stored in a repository, is the foundation for improving things, to automate. Following the concept of immutable infrastructure, we pack all components into Docker containers and build from scratch, everytime. Which then makes us independent of where to deploy to - locally on a dev machine, hosted or onto the cloud. So far we stayed away from using any cloud specific offerings, like Amazon EC2 or similar, but manage it all ourselves, using Docker machine, compose and swarm.
We ended the day with the public meetup - finally being able to have a beer helped to relax a bit - and where happy to see so many guests from Freiburg and around. It's so good and important to network, talk about experiences others had made, realizing how many of us work on the same topics!
Automated testing was another topic for discussion - is there a need for manual testing? How can others deploy several times a day and still test everything? Again, testing, development, deployment all moves closer together and therefore automating your test processes across the board is a natural goal - start with unit tests, system tests, don't forget security, include API testing, end-to-end and UI. Include it in your pipelines, set up the test environments from scratch and pull the test cases out of a repository (immutable infrastructure!). Then just make sure you can run it all fast - and here comes the challenge for us again. Test automation is not new for us, we have automated test cases - a lot in some cases. But combine all of those and you realize there is not enough time in a night to run them all!
So apart from the different tools and frameworks you can use - we talked about SoapUI, Selenium, HP Lean FT and others - we have to think about when to test what. And maybe restrict ourselves more, leave some tests out, not run them all, all the time. After all, testing being part of the build and deploy cycle, which is being streamlined, we can always redeploy. Combined with the Microservices approach, you deploy small pieces - so there is only so much which can go wrong in one deployment.
We ended the day with the public meetup - finally being able to have a beer helped to relax a bit - and were happy to see so many guests from Freiburg and around. It's so good and important to network, talk about experiences others have made, realizing how many of us work on the same topics!
We're already gathering topics for another DevOps day, hopefully soon!