During development you generate a fair amount of different artifacts. These might include:
The source code
The compiled application
A deployable package
and potentially others as well
While you could use a source control system to store all of them, it's usually massively inefficient, as source control systems are usually designed to handle ...
Continuous delivery and continuous deployment both take continuous integration one step further, by adding a 'deployment to production' step to the process.
The difference between continuous delivery and deployment is that for delivery this step is done manually and for deployment is it automatic.
Difference between Continuous Integration, Continuous ...
I normally use stackshare. It doesn't show you usage as reported by the people running the tools but it has a decent community size and seems to be gaining more use rather than less.
It lets you compare tool features, community popularity and shows you who else is using those tools in their stack if that matters to you.
I would keep the ECS container instances (I'm talking about the Docker hosts - I don't like AWS terminology here) and the deployment as two separate things.
Get your ECS stack up and running. You can manage it through CloudFormation and Auto-scaling groups, that's fine. Just think of your cluster as a platform where you will deploy to, not something you ...
Feature flags are an engineering device that can be used to avoid long-lived branch and conflicts in product development. Here is how it can be used the context of an object-oriented language to help developers collaborate on a specific product feature while one handle a new version. This solution can also be used in non object-oriented contexts, provided a ...
I am aware that there are practices such as only adding database objects, i.e. tables and columns, never modifying or removing them
At one company I worked for, a rolling window of raw data equated to about 6 months and ate up 10 TB. The data was then processed into an RDBMS format which cost 6 TB of usable data which accounted for about ...
Instead of Continuous Integration and Continuous Delivery, I would define the definition of done as "Active Continuous Improvement at all levels of the organisation".
The other topics like automated builds, CI/CD, etc... these are just milestones and most definitely not the ultimate goal for the organisation in its DevOps efforts.
It does look like it ...
I Googled "Push on Green" and the first link was:
This was representative of almost the entire first page. It looks like this term originated in Google's SRE group and has been taken up by the industry at large.
You are correct- "push on green" means that deployments are ...
I would integrate the schema management into the application itself (or along with it).
Any change to the schema should be committed along the application code (and hence tagged also).
There's already a bunch of possibilities listed in this question: What practices or tools enable Continuous Deployment of Databases
With this kind of tools, using an in ...
What exactly are they?
Here is a quote from reproducible-builds.org:
Reproducible builds are a set of software development practices that create a verifiable path from human readable source code to the binary code used by computers.
Why are they important?
IMO the easiest way to explain their importance is to consider them as a variation of a backup ...
Personally I don't see any reason for which an Artefact Repository - the recommeneded DevOps tool of managing artefacts - wouldn't be applicable to trained neural nets or other artefacts.
The artefact size might have some upper limit for a particular artefact repository, but in such case it would be a technical or policy limitation one, not a fundamental/...
The steps are quite "easy", to move to a feature flag app you need basically two things:
A flag repository (file/data base/env variable)
Conditional statements to change the behavior according to the flag.
The basic of feature flag is to turn them on/off, but quickly you'll wish to release a new feature in a ramp-up manner, for example: 1 server on 5 ...
I don't view DevOps as a job position. Yes, I also have job offers out there for titles like "DevOps Engineer" [sic], but that just means I am looking for people who mainly can take a team with little DevOps knowhow and guide them along (be it through just doing the bulk of the work, or evangelism or whatever). But at the end of the day, everybody on the ...
Sit and watch the pipeline run?
No, that is not how you work efficiently.
Developers push their commits to the source control repository and then the CI/CD pipeline is triggered.
Developers may post a well-written pull request anytime they want. There is usually a visual mark representing an "on-going build"/"failed build"/"successful build".
Typically a ...
There's repository managers and Universal package repository managers (UPM).
UPM’s can store all your build artifact for Jenkins, teamcity etc. and can generally also act as repository mangers for many different types of binary artifacts Maven, npm, NuGet and more.
These would be tools like Jfrog Artifactory, Inedo ProGet, and Sonatype Nexus.
A pretty ...
By default Jenkins assumes whether the build is SUCCESS or not from build process exit code.
Which means that build exit with code 0 considered as SUCCESS, rest all are considered as FAILURE.
If your build step/process exit with code 0, even during the failure case then Jenkins will report the build is SUCCESS.
So I my suggestion is to run the all build ...
I'd argue a tool alone won't really help unless you shift the schema responsibility to the application team.
We do use liquibase or flyway at work, where the application team is responsible to create the changesets.
Along with this,you can avoid a purely additive way.
Each application is required to be compatible with its precedent version, when an ...
Although not entirely relevant to your question in terms of popularity, devops bookmark is a very nice website which helps discover tools and frameworks in the DevOps landscape.
You are also able to filter tools and frameworks which works with different languages, platforms, licenses and topics which is really handy!
Immutable is exactly what it means, immutable, no change on configuration or code running or system library or whatever, if a change has to be made, create a new image and deploy it, never change it while running.
Source code updates are the least thing to change on a running server, this should not happen on a running server, immutable or not.
To answer this question in the context of a mainframe environment, and specific to DB2® databases, there are typically 2 commonly used (not cheap ...) alternatives to pick from:
Object Administration for DB2®, from BMC. Here are some details about it (quote from the linked page):
Making changes to objects in your database—or even just performing routine ...
We use liquibase at our work and I'll speak highly for it. It's also used by our QA tool QASymphony.
We're utilizing it against MSSQL and Oracle databases internally and QASymphony uses/has used it with both postgres + mysql instances.
We use Flyway at work for managing Postgres schemas in the app, and Pillar for managing Cassandra schemas. We have found it best if the app manages its own schema.
We had a horrible experience having ansible manage schemas before the apps managed their own schemas.
There are, as always, a few ways to solve this.
You can use a central source to keep secrets that each server reads from ala Hashicorp Vault. While popular this is not my preferred approach as its rather complex. There are quite a few key value stores that can provide similar functionality such as AWS Parameter Store.
You can manually put data in these ...
I think the major deciding factor is the expertise of you and the rest of your company in the chosen OS. If you are a Windows shop, and your company is willing to leverage the cost of the node, it's probably best choice to host it on a Windows VM. For choosing a Linux distro, I would see what is most common across your company. In my opinion, it is not worth ...
Personally I consider the distribution of the software to a target just an intermediary step of a deployment - installation/activation of that software being necessary to complete that deployment.
To me the delivery (as in continuos delivery) stops when the software to be deployed is created and made available for deployment (i.e. for distribution, ...
I would separate the CI and CD contexts, as the periodicity in one of them is rather loosely coupled to the periodicity in the other one.
That's primarily because CI attempts to produce versions of software available for delivery/distribution, see How does continuous integration relate to continuous delivery / deployment?
But not all CI executions are ...
Continuous delivery and continuous deployment (CD) are more or less the same thing*. Every time a change is considered 'good to go' (tested/verified) it should be release immediately. You can do this as many times a day as there is work completed.
Continuous integration (CI) only refers to merging code together often to ensure that feature branches don't ...
To provide a practical example of an attempt at creating a truly repeatable build consider the following -
A build pipeline which starts with a git repository for which no user can ever rewrite history or delete unmerged branches.
The first "build" step after checking out the source code is to spin up a container which contains all the build time ...