Evaluating your existing IaC provisioning process will help identify any pain points or areas for improvement. Consider factors such as collaboration, version control, infrastructure provisioning, and deployment. This analysis will help you identify key requirements for env0, ensuring a better fit for your team's workflows and objectives.
Depending on the company's security posture, the location of the code may be required to be within your (virtual) data center. Others are happy with the level of security held in SaaS repositories. The location of the code may push your solution one way or another.
env0 natively integrates with the most popular VCS (or SCM) providers; GitHub, GitLab, BitBucket, and AzureDevOps. Our built-in CI/CD pipeline allows for Plan on PR (or merge requests if you’re using GitLab), Continuous Deployment, and plans and applies from PRs using our PR comments feature. All of these features are options as is the ability to work as a VCS first or UI first user/business.
If your favorite VCS isn’t listed above don’t worry, we regularly review which VCSs should be added to our platform. In the meantime, we work with any VCS, with our “Other VCS” option. The only drawback is the native CI/CD features within env0 won’t work, but we can work with you to find the best way to trigger workflows.
env0 also works with the self-hosted versions of the VCSs previously mentioned (except AzureDevOps). In order, to connect to the self-hosted VCS providers, you will need to use the env0 self-hosted agent.
The decision to use the env0 self-hosted agent does not only depend on the type of VCS you are using, it can be a preference for many reasons. Perhaps your company has high-security requirements and you need all clones, runs, and logs within your (cloud) data center. We can work with you to decide the best solution for your business.
Depending on the DevOps maturity or preference, we see many of our customers fall into one of these scenarios. It’s great to evaluate where you are and where you want to be… Where is your bottleneck? Do you have self-service? Do you want self-service?
Whether your team is deploying your IaC manually, or it is automated through some CI/CD tool, the DevOps team is the major actor in this setup. We’ve found that the majority of customers are in this bucket, not because they necessarily want to be, but that is simply the current state. DevOps teams in this space typically are tasked through tickets, to create the infrastructure required by the application or teams they support.
- DevOps team provisions infrastructure through the TF code that they’ve written.
- DevOps responds to requests for Infra, and provision
Either you application developers or your platform consumers know some IaC, and you’ve given them the ability to submit PRs to modify the infrastructure code. You have a system that will thus create the IaC, through a PR process that creates the resources after the PR has been approved. You may have written a wrapper, to allow devs to “fill out a yaml/json form” to create the infra they require.
- Developers submit PR with TF code that they’ve modified or written
- PR approval ultimately results in the creation of resources
- Status Quo or Your Preference
- Config as code
- ALL infrastructure as code - even Developer Self-Service.
- Application teams take ownership of Infrastructure
- PR Approval process creates a paper trail
- Some fundamental knowledge of IaC is still required or the wrapper code needs to be maintained and extended as use cases expand.
- PR Approval Process is not always in line with the Infrastructure Approval Process.
- Deleting or removing resources requires someone to submit another PR.
You know that not everyone can learn infrastructure code, nor do they really want to. So you want a web UI, that will allow the engineers or developers to create new resources with some guardrails in place. The configuration is mostly configured in the UI, while you create a service catalog for your end-users to request or even create resources on-demand. Using IaC scanning tools and policy enforcement tools, you can create additional guardrails and approval policies while giving more engineers the ability to self-service.
- You Prefer
- Users can request infrastructure through a UI
- Guardrails like Security scans and Policy enforcement are in place.
- Approvals through UI
- No coding necessary
- Unified view
- Click Ops
- Configuration in UI
It’s the wild-west, any team can choose whichever tools they desire, leading to different processes for different teams, and disparate tooling. There may be a lack of sharing across teams on how best to get into production, but that’s okay. The other team is still deploying to on-prem data centers, while your team is on the bleeding edge of managed K8s.
- You Prefer
- Greatest flexibility
- Fully customized toolset for the application team
- Allowing fine-tuned control.
- Disparate tooling
- Higher cost in tooling
- Multiple pipelines
- Re-inventing the wheel
- Application team maintaining CI/CD pipeline instead of focusing on the application
Do you automate your TF deployments currently? or is it a manual process? What else are you doing in your CI/CD pipeline related to the infrastructure, and what does the handoff process look like?
<insert diagram of env0 in a CI/CD workflow>
The basic integration of env0 involves connecting env0 to your VCS and (optionally) enabling the CD functions (Plan on PR and Deploy on Push). This gives you the ability to trigger plans and deployments as your code changes.
- Policy enforcement - You want to make sure that tags are in place.
- Security scanning - Using an IaC static code analysis tool to scan for security vulnerabilities in your code.
- Secret fetching - Perhaps you want to store your secrets in a secrets manager, and you want to manage that process in a pipeline.
- Configure resources - Use configuration mgmt. tools like Ansible or SaltStack to automatically configure resources after they are deployed.
- Testing - After your infrastructure has been provisioned, you want to run some basic functional or integration tests.
- Notification - You want to notify certain users when a deployment has failed, or waiting for approval.
The options are limitless! What do you want to do or wish you could do before, during, or after resources are provisioned? env0 allows you to inject custom steps at any stage of the build process.
Do you currently have an automated scheduling of resources for creation and destruction, or automated drift detection?
env0 tries to minimize all those repetitive tasks as much as possible, and we are still building out ways to do so. Our scheduling feature allows you to build and destroy resources at specific times of the day, week, or month, using cron expressions. Drift detection can run on the hour, every hour, or whenever you want! Drifts can be flagged up with the env0 platform or we can let you know via Teams or Slack. We even have features such as workflow triggers allowing for automated promotions.
Are you currently promoting from a lower environment automatically, or manually?
Do you use a branching strategy (dev, stage, prod) to help manage the promotion of your infrastructure?
Or do you use a folder strategy for managing your various staging environments?
Whichever way you manage your environments through branches or folders, you can manage it in env0. With env0, you can automate your deployments, and automate your promotions, or you can manually approve each deployment. The addition of approval policies allows for special edge cases to be reviewed for manual approval.
Regardless of the way you work now, or the way you dreamt of working, env0 has the features and flexibility to allow you to meet your potential. Reach out to our Sales Team if you’d like to discuss any of the above concepts further.
Updated 5 days ago