30

During development you generate a fair amount of different artifacts. These might include: The source code The compiled application A deployable package Documentation 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 ...


21

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


13

Pramod Sadalage and Scott Ambler wrote a book Refactoring Databases: Evolutionary Database Design that is an incredibly solid primer to the subject of DBs in a CD org/team.


11

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


8

Conceptually, this approach is not the way to go; the build directory is not a deployment directory, it's a temporary directory, to build or to deploy from, whereas on a shell executor this could be fixed. So what you need is to deploy from that directory with a script as per gitlab-ci.yml below, to the correct directory of deployment. stages: - deploy ...


7

If you must adhere to the change process, you'll be limited according to the limitations of the change process, full stop. If changes must be approved prior to deployment, you cannot do continuous deployment. If approval takes a long time, you cannot deploy quickly. There's no workaround whereby you can both follow the process and not be impacted by it. That'...


7

You could look at tools such as Postman which focuses on testing REST APIs with JavaScript - it has some nice features but you lose the use of Python. Instead, I'd suggest looking at REST-related plugins for pytest, a Python test framework that simplifies your test code, while still running tests written using unittest. For example, writing parameterised ...


6

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


6

Snapshot Permissions Boto3 has a function that allows you to create volume permissions, which is what AMI Sharing with AWS Marketplace requires you to do. snapshot.modify_attribute will allow you to share your AMI with the marketplace account like so (you can also use a JSON representation if you prefer, it's in the docs): response = snapshot....


6

A good way to find comparison information about things like this is googling for "X vs Y", e.g. "Chef vs AWS stacks", "Chef vs Puppet" or something like that. That does turn out subjective information, and while it is nothing like having hands-on experience, you still get a few nice nuggets here or there. For example, Chef gives you the full Ruby language ...


5

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


5

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


4

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


4

What you've listed is actually two different things, continuous delivery and continuous integration. When people talk about CI they typically are only referring to the testing part; automated unit, function, and integration testing with some sort of version bump or code promotion at the end. Looks like the Jenkins wiki has some specific pointers about ...


4

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


4

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.


4

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.


4

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


4

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


4

As alluded to by Tensibai ♦, I think the answers you are looking for start from my answer to "What is SecOps?", specifically from the "Further Reading" section: DevOpsSec by Jim Bird DevSecCon: A DevSecOps Conference Velocity EU: Continuous Security Of the above I am currently reading Jim Bird's book, have had the pleasure of working with the organiser of ...


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

Monorepos are nice because it eliminates the technical constraints between multiple projects. This does however open the door to other complications within your repository (naming conventions, cross-team dependencies, merge conflict increases, etc.). I do not have any experience with CircleCI, but I will provide some input based on other CI tools I have used....


4

This is totally possible. Of course you can achieve it without jenkins or similar tools being required. We're always free to reinvent the wheel. The question becomes is it worth the effort? When it helps you avoid jenkins I'd be inclined to put the effort in. (I'd also suggest looking at Concourse before doing jenkins again, but that's not what this ...


4

Frankly, if you go this route, you do not even need Ansible as a CI/CD driver. Ansible does not bring any infrastructure anyways, it just uses an existing ssh connection, so you can just use said ssh connection directly with your own scripts. If the ultimate goal is to avoid any of the established solutions (Jenkins, Gitlab CI, whatever), then nothing ...


4

Assuming there are no changes in Master that are not in your release branch and you don't rebuild after you merge the code then you could deploy first and then merge to master. If either of those are not true, then merging first would be more common. The process depends on how you handle your branching strategy. If other things could be merged into ...


3

I found the solution while trying to manually deploy the Lambda function as a jar file. These are the steps - Create your Lambda function as a Maven project using the AWS documentation. Create your Jenkins job as a Maven project and specify package in the goals section. Follow the Jenkins Lambda plugin documentation for deployment and specify target/your-...


3

For me I use jenkins in docker with git plugin. The Git plugin will give you the ability to check the Git server every specific period of time or you can use git hook from github or bitbucket to trigger the task when ever any change happened to the repo or the branch. For deployment, most of time I use shell build step to execute some shell command on ...


3

For tools which don't offer access to a source code management repository that you can automatically query for updates you could start with a manual trigger, then take a closer look for how is that trigger activated by humans and maybe automate the task: there could be upgrade email notifications sent to a subscriber list. An automatic email processing ...


3

From your list of tools: Jenkins and Github have apt/yum repositories you can use to install and upgrade. For Atlassian products, best up to date information about repositories I can found is This ShipIt experiment and it seems unlikely to change from this forum post The workaround may be parsing the mailing list to update the deploy. Now if you really ...


3

I would hesitate to describe your once per day model as CI/CD, it sounds more like the "nightly build" model. It really depends on the nature of your work and processes. If things flow smoothly through building, testing, and preparation of an artifact for deployment and your development model / velocity isn't such that it would benefit from more frequent ...


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