11

Let's say you take out the master branch (you can rename develop to master to confuse your team if you like later) and simply use tags for releases either on develop or hotfix branches. You took out a branch, but the difference is just a change in syntax. Change for change sake. Now let's say you actually take out develop with keeping the locked master ...


11

IMO DevOps is culture, much like Agile (without choosing an agile methodology.) Therefore you don't "do" DevOps. You "do" a release methodology called Continuous Delivery as part of a DevOps Culture. (full disclosure, I don't think I've ever referred to CD as a release methodology before, but in my jetlagged state I think it works) If you'll buy that, then ...


7

Mainly an artifact is the result of of a build phase, this mean a package is an artifact of a kind. A package is usually a way to install a software or application, it includes the software itself and some intelligence to setup and configure the software. Calling an artifact a package usually comes when the artifact (whatever it is, from a .deb to a simple ...


6

I don't think there is a generic term for promoting to production. I can tell you that within the devops community, terms are frequently interchanged. As long as the point being addressed is well thought out and made clear, the point can be understood. Some of the terms that are used when referring to the movement between environments are deploy, propagate, ...


6

What you're after is an Binary repository manager Quoting from Wikipedia with added links: Notable Universal package managers include:[6] Apache Archiva Jfrog's Artifactory Inedo's ProGet Sonatype Nexus I know for sure Nexus and Artifactory match your requirements (even if proper UI is a bit subjective and you mileage may vary).


6

For software in the web app category, depending on you infra/hosting provider such decoupling might be possible to switch incoming traffic across (or split it between) different deployed versions of the sw, practically covering any of the changes you mention: bugfixes, visuals, etc. Such support would typically not require feature toggles. And it might be ...


6

IMHO the problems you're facing are just a side effect of the poor branch strategy you started with: you're effectively plowing new development on develop (i.e. what converges towards the future production code) through the current production code on master. This leads to contradicting requirements and problems since typicaly the future code diverges from ...


5

You are already building and testing code on each of the pull-request and hot-fix branches. This means that in aggregate, the sum of all branches pending on pull-request are your virtual develop branch. You can create a system when in a test environment, several pull-requests are cherry picked into a temporary branch that is not published to the main ...


4

One of the earliest references to this term originate in Jim McCarthy's book Dynamics of Software Development. This term seems to also be embedded in the Lean Startup movement, which built upon ideas in Lean Manufacturing, TRIZ, and other sources explaining how to evaluate an experimental product and check if it fits the market before investing too much ...


4

Your use of the term "devops" suggests that you see it as a role. I humbly suggest that developers that are part of a Scrum team aren't called "Agiles," so DevOps practitioners aren't "devops." :) Release management is absolutely part of DevOps. It's one of several specialty engineering roles. Staffing for the skill of release management varies widely ...


4

While with monoliths you might be restricted to switches, with microservice architectures, you can split every deployment pool of nodes providing a service (ie. pods). You then activate the deployment of the newly changed product in a subset of pool, and carefully monitor it; you can even choose which amount of the pool to deploy the change to, say for ...


4

A very interesting question. On the assumption that the goal of a Software Escrow process is to allow for a 3rd Party to take over or nominate an additional party to fulfil the responsibility of the software vendor, I would suggest the following elements of a DevOps operating model that would support software escrow: Infrastructure-as-code - effectively ...


4

One could consider to package the scripts. Depending on the distribution, e.g. ubuntu, windows, centos one could create a ppa, nuget or rpm respectively. Once a newer version is installed, the package manager will remove the previous version automatically. As yum or zypper could be used to install packages on OpenSuse one could consider to create an rpm by ...


4

Here is what works for us. We have a "version" file deployed with the application itself. Then, application issues a "check version" request periodically that checks if the version that the application has initially loaded is different from the version specified in this version file. If it is different, we show a notification that there is a new version ...


4

What you are primarily discussing is the hosting model for the underlying cloud you are using, for example, from what you have said so far your hosting model is relying on Infrastructure-as-a-Service (IaaS), and you want to have less responsibility for managing the Operating System. That being the case you would need to move right in the table below to ...


3

From Wikipedia: Release management is the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases. Depending on the context the term release is used to reference either of: the version of the software being released (from a version control ...


3

From my experience this is very provider specific and requires evaluating the SLA offered for a particular service. For example the siteground cloud server offerings shown at https://www.siteground.com/cloud-hosting.htm state: We preinstall and maintain all the software you need on your server. While offerings from liquidweb they make it clear they will ...


3

In DevOps, it is not always about just piciking the right tool, but understanding what is happening also in terms of the workflow. Interesting aspects are here delivered value (like saved time) and how the process can be scaled if you get more customers. Without knowing further details, I would suggest to investigate what your customers do after they have ...


3

Eric S. Raymond is credited with popularizing "Release Early, Release Often" in his essay "The Cathedral and the Bazaar" where he credits Linus Torvalds as using that approach in the development of Linux to it's success.


2

Not sure if there aren't any others, but these are the criteria I use: +-------------------+-----------+-----------+ ! Criteria ! Agile ! Waterfall ! +-------------------+-----------+-----------+ ! Release Events ! Frequent ! Rare ! ! Risk ! Less ! High ! ! Required Effort ! Smoother ! Peaks ! ! Volume of ...


2

Well @dan-cornilescu says it well for your particular problem, but the more general case for Trunk-Based Development (mentioned in the Continuous Delivery, Lean Enterprise, and The DevOps Handbook) is made here: https://trunkbaseddevelopment.com/


1

Do not trigger Build 2 automatically from Build 1. Instead add a last step to Release 1 to queue Build 2. There are a few ways to do it, e.g. https://stackoverflow.com/questions/52821204/how-to-queue-build-pipeline-as-task-from-release-pipeline


1

def repository = 'git@somerepo' import hudson.tasks.Shell job = Jenkins.instance.createProject(FreeStyleProject, 'TestJob') job.setDescription("Some description") job.displayName = 'SomeTestJob(TESTING groovy)' job.scm = new hudson.plugins.git.GitSCM(repository) job.scm.branches = [new BranchSpec('*/master')] job.save() Thanks a lot Michael Durrant for ...


1

Normally the build configuration needs to stay consistent with the product code, so it should be stored into the same git repo as the product code. It's true, the file would get merged when a branch merge from the parent is performed. But often it's a trivial (empty/fast forward) merge - if there were no changes to the msbuild xml file in the parent ...


1

But to actually "process the SE-deposits" (by the SE-agents), all sorts of release management and/or software delivery tasks need to be performed by somebody or something (the poor SE-agent) who probably doesn't know at all what the licensed software is supposed to do ... fun guaranteed! I wouldn't do business with an SE provider which would allow ...


Only top voted, non community-wiki answers of a minimum length are eligible