Rundeck: Change Management process

152 views
Skip to first unread message

Vince H

unread,
Jun 3, 2014, 1:08:14 PM6/3/14
to rundeck...@googlegroups.com
Hi,

We're looking to get some ideas on how people in the (Rundeck/DevOps) community approach change management within Rundeck projects or jobs.

We have various environments (Dev, QA, Staging, Prod) which, in Rundeck terms, are Project (with unique node definitions). Our goal is to migrate projects in sequence from Dev to Prod.

The obvious way to do this now is Exporting the project (Dev) through the UI, and Importing the archive to another project (QA), and so on up the chain. To be able to easily identify diffs in the jobs would be extremely useful too (source control the job xml?)

Does anyone have a similar process/workflow that they can share?

Thanks!
Vincent-

Ryan B

unread,
Sep 21, 2016, 4:23:26 PM9/21/16
to rundeck-discuss
Sorry to revive an old post.  I was just wondering if anyone has new input for this old question?  I too am wondering the best way to go about promoting changes for rundeck itself as well as the projects it manages.

thanks.
--ryan

Jiří Hlinka

unread,
Oct 10, 2016, 2:27:27 AM10/10/16
to rundeck-discuss
Does the Git export and import (SCM) functionality suit Your needs? It does for us but maybe its not a solution that fits  everyone.

Jiri

Dne středa 21. září 2016 22:23:26 UTC+2 Ryan B napsal(a):

Pavol Gressa

unread,
Oct 11, 2016, 5:18:42 AM10/11/16
to rundeck-discuss
As I mentioned somewhere: 
- we have two rundeck instances, production one where no one have edit rights except few people, and testing rundeck where people can edit jobs.
- every job xml/yaml is placed in git repo that is periodically uploaded to production rundeck - so we have some configuration management over jobs and auditing 
- to eliminate waste in form of duplicates we've developed simple templating system for projects and jobs. So we have kind of project definition with references to templates that should be part of that project, plus content of the project xml/yaml is preprocessed and some placeholders are replaced with value defined for given project
- project itself is managed by our puppet recipe

Personally I believe that configuration management is hard to unify as there is lot of use cases and approaches how are companies using Rundeck. But auditing is another story and some internal functionality should be provided in order to audit changes to project and jobs configuration.
Reply all
Reply to author
Forward
0 new messages