Continuous Lifecycle: Bursting with DevOps and CD goodness The conference schedule for Continuous Lifecycle is virtually complete, with something for everyone - as long as they want to get deep into DevOps, Continuous Delivery, Agile and Microservices. We’ve had a steady stream of additions to the programme over the last week, with talks covering databases and devops, going deep into …
the multitude of recent DevOps articles and I've read most of them. Seriously as most of the UK's business income is made up of small businesses and to be consistently employed a company has to align itself with the customers needs with scope for future development, I am still at a total loss as to what DevOps and micro services actually are apart from as I understand it, another departmental layer in a large firm between the people writing software and those using it.
Naturally if I am entirely wrong then the scope of the articles has either failed or worked in that I'd need to go on a course if I didn't want to work with small businesses any more.
As far as I understand it it's meant to encompass any tools and methods for using automation to make code management, testing and release easier for developers, as well as using them to standardise environments, reducing the chances of bugs cropping up as a result of, say, a different version of Apache on development machines and production
With web applications you might have it so, when code is merged into a testing branch it spins up a test environment using the same software versions etc as live, runs through any unit and functionality testing, then either forwards it on to QA for testing or back to development. Then once QA has tested it they can either reject the merge and send it back to the developer or queue it for release without needing to talk to someone who does release management. Desktop software would be similar, but would also do test builds and wouldn't release to production for initial release, then would be used for managing and releasing patches
Of course it does rely on it being properly implemented, as a bad implementation would probably result in more work/problems than doing without, and it also needs to be adapted to whatever your working at. It's nothing new really, just a shiny new badge which makes it a bit easier to sell management on letting you dedicate some time to something which should really be getting done anyway
Devops is just your release team.
They will build and deploy your code in a consistent manner across your Dev, testing and production environments.
They do this using things like Jenkins, maven, msbuild, nant and other scripting frameworks.
In most places, they are also starting to manage change as well as building out environments, so they will use shell scripts, powershell, python etc.
If you are not in devops, then this will help you understand. Granted, many devops people will say this is an understatement, which is correct.
Just how do developers and PM'S think their code gets from the devs to where it needs to be?
Oh, final note, if you are a Dev shop with two or three devs, then you don't need a devops team, the devs themselves should be mature enough to handle things like deployments
My release team is two scripts - one to package and one to deploy. It never occurred to me I could've built an industry around this.
By the way, is Maven still the slow, bloated, productivity sapping monstrosity I came across 5 years ago, or has it got even worse?
If you work for an organisation that produces a piece of software that doesnt need multiple levels of testing and deployment, thats great.
But, if you are working for an organisation that has multiple dev teams split across the globe that produces software that needs to be distributed across the world, you might need more than two scripts.
Basically, its up to the organisation to decide how much it wants to invest in devops. If you dont need it, then dont use it. No point in making life more complicated
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
