Deployments with containers

This post is part of The Containerization Chronicles, a series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

Now that we have the project integrated with a Continuous Integration server, where we run the tests and report back to GitHub pull requests with the results of the test run and the coverage, we can deploy our project and make it available on the Internet.

We will do so with Heroku. I have chosen Heroku because it allows me to perform these experiments for free.

If you want to jump into the code, this is the tag for this post.

Continue reading “Deployments with containers”

Advertisements

Integration with CodeCov

This post is part of The Containerization Chronicles, series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

This is a fairly small post, as it is really simple to integrate with CodeCov. Follow the instructions on their website to create your account and set up the repository and follow along with this post.

To be honest, we don’t even really need this integration at this point, because Scrutinizer can already give us a nice badge for the code coverage, as well as fail the build if the coverage degrades. Nevertheless, CodeCov gives us all that plus a much more detailed report about the coverage than just the final coverage rating, and the possibility to fail the build if the coverage of the pull request is below the limit, or results in a global coverage below the limit.

If you want to jump right into the code, this is the tag on GitHub.

Continue reading “Integration with CodeCov”

Continuous Integration with containers

This post is part of The Containerization Chronicles, a series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

Now that we have some containers in place for development, we can integrate with a CI server. I chose Scrutinizer CI because of the code analysis it makes, the fact that it is also a CI server it’s a plus. However, as a CI, it has some limitations, which I will talk about later on when integrating with Heroku, so we will most likely move to another CI engine later in the future while keeping Scrutinizer only for the code analysis but, for now, this is all we need.

To set up the CI, we will:

  1. Containerize an environment to run the tests in the CI
  2. Configure Scrutinizer
  3. Add the scrutinizer badges to the README.md
  4. Integrate Scrutinizer with GitHub

If you want to jump right into the code, this is the tag on GitHub.

Continue reading “Continuous Integration with containers”

Containerize development

This post is part of The Containerization Chronicles, a series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

EDIT:

I changed the title of the post from “Containerize dev, tst and prd” to “Containerize development” because that is actually my goal here, although I do create the production image here, and some ppl were getting confused, thinking about the CI test environment and the production environment we will deploy to.

After cleaning up the Symfony demo project a bit, we are ready to do some containerization…

I will talk about:

  1. Logging
  2. Containerizing development
  3. Run and stop the containers
  4. Remove database from VCS
  5. Integrate with PHPStorm

If you want to jump right into the code, this is the tag on GitHub.

Continue reading “Containerize development”

Cleaning up the demo project

This post is part of The Containerisation Chronicles, a series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

In order to start making experiments with containerization of applications, I am going to be using the Symfony demo project, which is a small blog where one can view and create some blog posts. Although it is a very small project, and therefore does not reflect the complexity of an enterprise cloud application, I feel it is flexible enough to experiment containerization practices, especially because I want to start small.

However, there are some things I don’t like about the project, so I start by doing some cleanup:

  1. Add roave/security-advisories
  2. Remove simple-phpunit, update to phpunit 7 and DAMA bundle 5
  3. Disable the profiler during test runs, so the tests run a bit faster
  4. Type hint all the things
  5. Change namespace from `App` to `Acme\App` to better comply with PSR-4
  6. Add a Makefile so we abstract our DevEx and automation from the tools

If you want to jump right into the code, this is the tag on GitHub.

Continue reading “Cleaning up the demo project”

The Containerization Chronicles

While working on the 18th post of The Software Architecture Chronicles, which is about implementing a proof of concept, I picked up the Symfony demo app and started refactoring away…

I started by cleaning up the project a bit and adding some functionality I like to have for better DevEx (development experience), but after some 20 commits I got annoyed with it and decided to try to get the environment as best as I could.

More or less at the same time, at work, we are currently moving to containers, and Kubernetes, and this would be a nice project to start diving into that.

So here it is, “The Containerization Chronicles”, a series of posts where I will be describing my experiments and learnings about the containers world.

I will be using the same repository as I will use for The Software Architecture Chronicles, so you will be able to access all the code there.

Posts in The Containerization Chronicles:

  1. The Containerization Chronicles
  2. Cleaning up the demo project
  3. Containerize development
  4. Continuous Integration with containers (using Scrutinizer)
  5. Integration with CodeCov
  6. Deployments with containers (using Heroku)
  7. Add an Nginx container
  8. Replace the Nginx container for httpd
  9. Replace the httpd container for httpd+mod_php
  10. Make a benchmark on the previous 3 configurations
  11. Add a persistence container
  12. Start diving into Kubernetes… No idea what I’m gonna do here…

Just created hgraca/doctrine-test-db-regeneration-bundle

While working on the next post of The Software Architecture Chronicles I ended up creating a little symfony bundle which I called hgraca/doctrine-test-db-regeneration-bundle to generate and regenerate the tests database used by a phpunit tests suite.

It is inspired by some code that Luis Cobucci wrote back in 2017, and it uses the Doctrine fixtures to generate a backup of the tests DB, which is then put in place just before every test method and removed just after every test method.

It has 3 options:

  1. We can opt to use an existing tests DB backup, if it is available. This saves us the time to generate the DB, but it will not be useful if we want to test queries that are based on time like “select all users created in the last hour” because if the backup is older than 1h our tests will fail;
  2. We can opt to not put in place a new copy of the DB at the beginning of a test method, so that we can safely use the DAMA\DoctrineTestBundle together with this bundle;
  3. We can opt to not remove the DB at the end of a test method, so that we can safely use the DAMA\DoctrineTestBundle together with this bundle.

You can check out the bundle here: hgraca/doctrine-test-db-regeneration-bundle

Hope it’s useful for more people and constructive feedback is always welcome.