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'...


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 ...


7

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

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

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 ...


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).


5

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 ...


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 ...


5

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

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

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

I'd set up my CI system to do this on every commit to master, that is, after the release branch merges. The first very straightforward reason for this is that the commit to master gets tagged with the release, and you want the thing you ultimately publish to match exactly the version of the source code at the tag. While there shouldn't be any merge ...


4

You need to separate the 2 concepts a bit: the integration part - how are the changes integrated into your master branch (or some other integration branch, that's also possible), which may be continuous or not. Technically neither approach you describe is actually continuous integration unless your feature branches have a very short lifespan - typically ...


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 ...


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

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

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/


2

... by making a minor change in the v1 front half, this breakage can be avoided. The above excerpt of this queston reminds me of something similar from around the late 90s, say 1996-1999 (when zillions of ITers were preparing for Y2K ...). In those days, new software releases of huge software vendors would come with release notes that included things like ...


2

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 ...


2

I am not sure about other approaches, but the one that I use is a modification of #3. There's usually a classification of releases (for example think of Ubuntu LTS and regular release). For the regular release, I would just release a new version and add a new tag. For LTS/Stable releases I would delete a tag pointing to a faulty release or change a commit ...


2

I'm building a product to solve this problem among others - https://relizahub.com (note it's pretty early stage at the moment). Idea goes as following - for all your releases you stream their details to Reliza Hub. You would then have a client that would pick up releases you need based on combination of tags, approvals, etc. So it is somewhat similar to ...


2

This question as it is posed is quite leading - the use of adjective "bad" to describe what you are doing implies that there is a "good" way. Nobody can answer whether your process is "good" or "bad" but you, and it should be judged on the effectiveness of the process. Perhaps this way of doing things is good for your ...


1

You can use Terraform for azure to handle the dynamic creation of azure resources in the release pipeline in Azure DevOps. Terraform maintains a state file for all the created resources after a run. If the script is run multiple times, it ignores already created resources unless there are any properties updated and created new resources. FYI, follow below ...


1

GitLab is a solid good option for most of this (with the appropriate plan level - I don't think the CE one has everything). It's a single-pane-of-glass for your code, security, CI/CD, metrics, etc. You can create and deploy to kubernetes clusters from it. You can have multiple environments and it'll store the secrets for you to customize them. It will ...


1

What is the recommended practice? The book ”Accelerate” by Forsgen, Humble and Kim documents their research that teams that use fewer long-lived branches are more successful. The question is then what is the best minimum set of branches for a given team. The answer to that, like many things, is ”it depends”. A team that pushes into production a dozen times ...


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