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 ...
There is no "Deploy-once-a-day" rule in devops philosophy. It's more of: Deploy as soon as possible and as often as possible. Also it calls for decoupling architecture so different parts of it may be released separately and also for decoupling deploys from release.
The Deveops Handbook by Gene Kim et al.calls for modifying Definition of Done to include ...
What you're after is an Binary repository manager
Quoting from Wikipedia with added links:
Notable Universal package managers include:
I know for sure Nexus and Artifactory match your requirements (even if proper UI is a bit subjective and you mileage may vary).
Instead of using Travis' deployment features, build the deployment logic in to your normal "test" script(s). For a PaaS this might be as simple as pushing to another git remote if all tests pass, but the sky is the limit.
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 ...
I don't think there's a good answer that applies to all software packages or situations.
Rolling releases are more risky as there is no predictability around when things will change. You may have installed the thing last night and already there's an update to deal with. But what does that update do? Is there enough information to know if you want it? ...
Travis CI supports deployment on branch release by using the following syntax:
The problem is that GitHub does not support it.
As per GitHub Releases Uploading page at Travis CI:
Please note that deploying GitHub Releases works only for tags, not for branches.
For GitHub the only workaround is to push tags (e.g. git ...
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 ...
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 ...
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 ...
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 ...
As Michael mentioned, offer a standard solution based on release versions/numbers, with a reasonably long lifespan for your industry (maybe interleaved with one or more shorter lifespan intermediate versions, if it makes sense for your typical customers).
Give your customers the option to embark on this standard release track, maybe with a decent migration ...
For a laptop, desktop or standalone server, consider trying out Docker containers. These containers are designed to allow you to provide differing libraries, packages and shared objects uniquely to each application. You can have several different Docker containers running different and even conflicting libraries for the same application. You should be able ...
Have you considered setting up a build server (i.e. Jenkins, TeamCity) with disposable build agents?
If you do it in the cloud (i.e. via ec2 integration), you can literally set up an AMI with generic dependencies, then configure it to spin up a new VM for each build agent, which can be configured whichever way, and then delete the VM once you've done ...
Some great answers here, but I thought I'd chime in with an example of how we deliver features. "shipping" to production is not the goal, the goal is to deliver value. Shipping code to production is a means to an ends and we usually deploy many times to enable a feature. Here's a contrived example using a 1 week sprint for succinctness.
During planning on ...
The Agile software development method
describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and ...
In a sense your question exactly underlines the problem faced by teams trying to be agile but without having the benefits of a good DevOps culture in place: there is practically no guarantee that at the end of each sprint they'll be able to deliver to their customers.
In some cases teams may end up using more relaxed definitions of done (like passed QA in ...
This was answered via StackOverflow by Kevin Lu:
In short, the second suggestion he made to update to PowerShell 7 and adding the environment information worked. I also had to run the script to reregister the Azure agent on the target server.
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 ...
You can separate the steps, especially as it would let you do divide the work among different agents. You can also leave them in a single agent if you wish.
The primary advantage I see is leveraging different pools for different sets of work.
With releases last I checked variable scope was limited (as of 2018) to the "phase".
I wouldn't necessarily ...
Maybe if you maintained branches per versions instead of per customers it could help reduce their number?
Otherwise the only way to really get away from it is to be able to host the software yourself and switch to a SaaS model where you would be able to maintain only one version of it.
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 ...
I'm not clear how a Sprint which is timed-box to a predetermined length (1/2/3 weeks) fits with a DevOps principle of being able to deploy on demand or as needed.
As usual, there is no commonly agreed-upon definition of DevOps, or description of what it entails, so we're just spouting opinions here. But in mine, DevOps encourages operations engineers to do ...
A rolling release is newer, with cutting-edge functionality, but potentially more defects. LTS is more stable. If stability is your priority (as it generally is for DevOps), LTS would be the release to use.
Note: Deploying your own code often is unrelated to choosing between a bleeding edge or LTS release of a third party product. You want your external ...