Group items tagged

manually write state with terraform state push. This is extremely dangerous and should be avoided if possible. This will overwrite the remote state.

The "lineage" is a unique ID assigned to a state when it is created.

Every state has a monotonically increasing "serial" number.

checked automatically but requires human intervention to manually and strategically trigger the deployment of the changes.

instead of deploying your application manually, you set it to be deployed automatically.

.gitlab-ci.yml, located in the root path of your repository

all the scripts you add to the configuration file are the same as the commands you run on a terminal in your computer.

GitLab will detect it and run your scripts with the tool called GitLab Runner, which works similarly to your terminal.

each commit is considered a separate unit of change.

By writing clear commit messages, you can make it easier for other people to follow along and provide feedback.

Pull Requests initiate discussion about your commits.

If you're using a Fork & Pull Model, Pull Requests provide a way to notify project maintainers about the changes you'd like them to consider.

Pull Requests are designed to encourage and capture this type of conversation.

You can also continue to push to your branch in light of discussion and feedback about your commits.

With GitHub, you can deploy from a branch for final testing in production before merging to master.

If your branch causes issues, you can roll it back by deploying the existing master into production.

your changes have been verified in production, it is time to merge your code into the master branch.

learn about is SSHKit and the various methods it provides

SSHKit was actually developed and released with Capistrano 3, and it’s basically a lower-level tool that provides methods for connecting and interacting with remote servers

on(): specifies the server to run on

within(): specifies the directory path to run in

with(): specifies the environment variables to run with

run on the application server

within the path specified

with certain environment variables set

execute(): the workhorse that runs the commands on your server

upload(): uploads a file from your local computer to your remote server

capture(): executes a command and returns its output as a string

upload() has the bang symbol (!) because that’s how it’s defined in SSHKit, and it’s just a convention letting us know that the method will block until it finishes.

I recommend you take a look at SSHKit’s example page to learn more

make sure we pushed all our local changes to the remote master branch

run this task before Capistrano runs its own deploy task

actually creates three separate tasks

I created a namespace called deploy to contain these tasks since that’s what they’re related to.

we’re using the callbacks inside a namespace to make sure Capistrano knows which tasks the callbacks are referencing.

custom recipe (a Capistrano term meaning a series of tasks)

/shared: holds files and directories that persist throughout deploys

When you run cap production deploy, you’re actually calling a Capistrano task called deploy, which then sequentially invokes other tasks

Deployment is hard and takes a while to sink in.

These specialized roles create efficiencies within each segment while potentially creating inefficiencies across the entire life cycle.

Grouping differing specialists together into one team can reduce silos, but having different people do each role adds communication overhead, introduces bottlenecks, and inhibits the effectiveness of feedback loops.

devops principles

develops a system also be responsible for operating and supporting that system

Each development team owns deployment issues, performance bugs, capacity planning, alerting gaps, partner support, and so on.

Those centralized teams act as force multipliers by turning their specialized knowledge into reusable building blocks.

Full cycle developers are expected to be knowledgeable and effective in all areas of the software life cycle.

A full cycle developer thinks and acts like an SWE, SDET, and SRE. At times they create software that solves business problems, at other times they write test cases for that, and still other times they automate operational aspects of that system.

the need for continuous delivery pipelines, monitoring/observability, and so on.

Tooling and automation help to scale expertise, but no tool will solve every problem in the developer productivity and operations space

Trunk-based development is a more open model since all developers have access to the main code. This enables teams to iterate quickly and implement CI/CD.

Developers can create short-lived branches with a few small commits compared to other long-lived feature branching strategies.

Gitflow is an alternative Git branching model that uses long-lived feature branches and multiple primary branches.

Gitflow also has separate primary branch lines for development, hotfixes, features, and releases.

Trunk-based development is far more simplified since it focuses on the main branch as the source of fixes and releases.

Trunk-based development eases the friction of code integration.

trunk-based development model reduces these conflicts.

Adding an automated test suite and code coverage monitoring for this stream of commits enables continuous integration.

With continuous integration, developers perform trunk-based development in conjunction with automated tests that run after each committee to a trunk.

Instead of creating a feature branch and waiting to build out the complete specification, developers can instead create a trunk commit that introduces the feature flag and pushes new trunk commits that build out the feature specification within the flag.

Short running unit and integration tests are executed during development and upon code merge.

Automated tests provide a layer of preemptive code review.

A repository with a large amount of active branches has some unfortunate side effects

Merge branches to the trunk at least once a day

The “continuous” in CI/CD implies that updates are constantly flowing.

All jobs will share the same environment, if many of them run simultaneously they might get into conflicts.

storage management (accumulating images)

all containers would share the same Docker daemon.

Add privileged = true in the [runners.docker] section, the privileged mode is mandatory to use DinD.

To avoid that the runner only run one job at a time, change the concurrent value on the first line.

functional tests depending on a database.

Docker Compose allows you to easily start multiple containers, but it has no more feature than Docker itself

mark all jobs as interruptible as it doesn’t make sense to wait for builds and tests based on old information.

only running it when specific files have changed

To prevent the ‘vendor’ and ‘node_modules’ folder from being regenerated in every job, we can configure a build job for composer and npm assets.

To share assets between multiple stages, Gitlab has caches and artifacts. For dependencies we should use caches.

The pull-push policy is the default, but specified here for clarity.

All consecutive runs for the build step with the same ‘composer.lock’ file don’t update the cache.

composer prevents this by caching packages in a global package cache,